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(54) Electronic commerce settlement system 

(57) In an electronic commerce settlement system, 
a processing unit (3) in a financial institution freezes an 
account balance at a request from a purchaser, gener- 
ates provisional settlement money, that is, money infor- 
mation, and transmits the money to a purchaser's 
processing unit (1). The purchaser's processing unit (1) 
transmits a goods order request and provisional settle- 



ment money to a seller's processing unit (2). The 
processing unit (3) in the financial institution makes a 
final settlement for the provisional settlement money 
based on a final settlement admission request from the 
purchaser who received goods and a final settlement 
request from the seller who received the provisional set- 
tlement money. 
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Description 

Background of the Invention 

Field of the Invention 

The present invention relates to a provisional set- 
tling system, an encryption interchange system, a deliv- 
ery system, and a digital contents sales system in which 
payment for goods or services is made from a payer 
(purchaser, service requester, etc.) to a payee (seller, 
service provider, etc.) as provisional payment according 
to money information as digital data containing provi- 
sional settlement information, and the payer or a check- 
er, who checks an object for which the payment is made, 
carefully checks the contents of the received goods and 
services before the final settlement. 

Description of the Related Art 

As for conventional payment means, payment is 
popularly made in cash, by check, note, transfer be- 
tween banking accounts, prepaid card, and credit card. 

Common payment methods are prepayment meth- 
ods in which payment is made before receiving goods, 
immediate payment on receipt of goods, and delayed 
payment after receipt of goods. However, in any of these 
payment methods, a purchaser is subject to a risk of re- 
ceiving goods and a payment risk, whereas a seller is 
subject to a collection risk of receiving payment. 

That is, in the prepayment method, a purchaser is 
subject to the risk of receiving goods, namely that the 
purchaser may not receive goods even after the pay- 
ment is made by any payment means, or the purchaser 
may not be satisfied with the received goods. There also 
may arise the payment risk that the already paid money 
will not be refunded. 

In the immediate payment on receipt of goods, a 
payment means is limited to cash, check, etc. Further- 
more, although a purchaser can receive goods in ex- 
change for the payment, the purchaser cannot carefully 
check the received goods. Therefore, the purchaser is 
subject to the risk of receiving goods, in that the received 
goods are not satisfactory. There is also a payment risk 
as in the prepayment method. 

In the delayed payment after receipt of goods, how- 
ever, a seller is subject to the collection risk, in any of 
the above described payment means, that the expense 
cannot be collected even after goods are delivered. 

When a purchaser is not satisfied with the contents 
of the received goods, he or she can return the goods 
to the seller of the goods. However, the purchaser is also 
subject to the risk that the paid money is not refunded, 
and it may take a long time to get it back even if it should 
be successfully refunded. 

Furthermore, another problem may arise with digital 
contents such as software, image data, etc. transmitted 
through a communications network. That is, such intan- 



gible goods are subject to the risk that a purchaser may 
refuse the payment by insisting the poor quality of the 
received goods even after the goods have been suc- 
cessfully delivered to the purchaser. 

s When the above described digital contents are mar- 
keted through a network, there can be various risks such 
as an illegal use risk by the third party, an illegal substi- 
tution risk, a privacy infringement risk relating to inter- 
pretation (wiretapping) by the third party, etc. 

10 At present, it is considered that an encryption proc- 
ess method is the most effective method for reducing 
the above described risks. However, since the present 
encryption process method requires a public key, a com- 
mon key, etc. of each other between the source and the 

'5 destination (receiver) of data, a complicated process 
should be performed including user authentication. Fur- 
thermore, encrypted data cannot be transmitted be- 
tween the source and the destination unless the encryp- 
tion interfaces including the application for encryption 

20 are optimally set at both sides. 

As described above, in the conventional settlement 
system in any payment method with any payment 
means, a payee such as a seller of goods, a service pro- 
vider, etc. is subject to a collection risk, and a payer such 

25 as a purchaser, service requester, etc. is subject to a 
risk of receiving goods or a payment risk. Both payer 
and payee are subject to a risk of returning goods. 

In transactions through a network, both payer and 
payee are subject to various risks such as an illegal use 

30 risk by the third party, an illegal substitution risk, a pri- 
vacy infringement risk by wiretapping by the third party, 
etc. 

Summary of the Invention 

35 

The present invention aims at providing a settle- 
ment system capable of safely trading in goods (or a 
commodity) through a network or without a network (of- 
fline) with the above described various risks removed 

^0 using a payment means such as electronic money (elec- 
tronic cash) of money information including provisional 
settlement information, an electronic check, an electron- 
ic note, a provisional settlement card, etc. in a definite 
and simple procedure. 

45 in the first configuration according to the present in- 
vention, a provisional settlement system includes a unit 
for transferring to the payee the money information con- 
taining the provisional settlement information, which is 
settled upon receipt of the confirmation notification that 

50 an object item for which payment is to be made has been 
executed; and a unit for finally settling the money infor- 
mation based on a confirmation notification that the ob- 
ject item has been executed. 

With the above described configuration, a payer 

55 (purchaser of goods, service requester, etc.) can indi- 
cate his or her payment capacity to the payee (seller, 
service provider, etc.) according to the provisional set- 
tlement information contained in the money information 
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when he or she purchases goods or requests a service. 
The payee can secure the expenses for the goods or 
services according to the provisional settiement infor- 
mation. Therefore, the payee can solve the problem of 
a collection risk. When a transaction is processed 5 
through a network., a payee can easily authenticate a 
payer by issuing a request for final settlement of the 
money information containing the provisional settlement 
information. 

The money information containing the provisional 10 
settlement information settled upon receipt of the con- 
firmation notification that the object item has been exe- 
cuted is generated by an issuing financial institution. 
The information is fixed in the balance in the account of 
the payer in the issuing financial institution. It is desired 
that the money information contains the data about the 
amount of purchased goods or the amount of services 
which cannot be transferred until the final settlement is 
made, and contains the authentication of the issuing fi- 
nancial institution. 20 

With the above described configuration, a payee 
can confirm with authentication of the issuing financial 
institution that the issuing financial institution has se- 
cured in the account of the payer the money information 
containing the provisional settlement information settled 25 
upon receipt of the confirmation notification that object 
item has been executed. Therefore, an object item (pro- 
viding goods, services, etc.) can be executed without 
depending on a payer's personal credit. A service refers 
to, for example, nursing, white -ant exterminating, cook- 30 
ing, washing, cleaning, and field work of cleaning quilts, 
carpets, etc. 

It is desired that the money information containing 
the provisional settlement information includes object 
information about an object for which payment is made. 35 
When the money information containing the provisional 
settlement information includes the object information 
about an object for which payment is made, the issuing 
financial institution can confirm necessary information 
according to more detailed information at the final set- 40 
tlement and can effectively avoid the occurrences of ac- 
cidents in the settlement performed in response to an 
illegal settlement request. Furthermore, it prevents a 
payer from using the money information containing the 
provisional settlement information for other uses. *s 

In addition to the above described configuration, the 
system can be designed to include a unit for storing a 
final settlement request from a payee, a unit for storing 
a final settlement admission request from a payer, and 
a unit for performing the final settlement in response to so 
the stored final settlement request and the final settle- 
ment admission request. 

With the above described configuration, the pay- 
ment risk of a payer can be avoided because a final set- 
tlement request from a payee is accepted but the final 55 
settlement is not performed without a final settlement 
admission from the payer 

It is desired that the above described system in- 
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eludes a transaction management device for mediating 
transaction information to be transmitted and received. 
The proceedings of a transaction cannot be confirmed 
if the transaction is processed only between the parties 
involved. However, the transaction management device 
can correctly understand the entire proceedings of the 
transaction by transmitting and receiving transaction in- 
formation among a payer, a payee, a confirmor (receiver 
of goods, services, etc.) who confirms an object for 
which payment is made, a financial institution, etc. 
through the transaction management device. 

The above described system can include a unit for 
issuing a final transaction settlement admission request 
used when goods are purchased through the above de- 
scribed system, and a payer or a goods receiver trans- 
mits as authentication information the first third-party re- 
turn-of -goods certification information containing a pay- 
ment ID relating to the purchase of goods. 

A goods purchaser issues a cancellation request to- 
gether with, as authentication information, return-of- 
goods certification information certifying that a return- 
of-goods request has been received. Thus, the purchas- 
er can also issue a transaction cancellation request to 
quickly proceed with the cancellation process. 

In the above described system, the payee can be 
provided with a unit for monitoring a final settlement ad- 
mission request or a retum-of-goods request; and a unit 
for transmitting as authentication information the third- 
party delivery certification information containing a pay- 
ment ID relating to the purchase of goods, and for issu- 
ing a final transaction settlement admission request 
when the final settlement admission request or the re- 
turn -of -goods request is not issued within a predeter- 
mined period. 

With the above described configuration, a payee 
manages the term from the receipt of goods by a pur- 
chaser to the issue of a final settlement admission re- 
quest or a return-of -goods request, monitors whether or 
not a final settlement admission request or a retum-of- 
goods request is issued during the term, and issues a 
final settlement admission request together with the de- 
livery certification information, which informs that goods 
have been delivered to a purchaser, of the transaction 
management device as authentication information 
when none of the above described requests have been 
issued. As a result, the payee can issue a final settle- 
ment admission request on behalf of the purchaser to 
quickly proceed with the final settlement process. 

According to the second configuration of the 
present invention, an encryption intermediate system, 
which includes a transaction management device for 
mediating data from the first party to the second party, 
has a unit for encrypting data using a unique encryption 
key between the first party and the transaction manage- 
ment device and issuing a request to the transaction 
management device to transmit the data to the second 
party when the first party transmits the data to the sec- 
ond party. 
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With the above described configuration, the trans- 
action management device in the encryption intermedi- 
ate system and the first and second parties who transmit 
and receive encrypted data manage unique encryption 
and decryption keys. A transmitter transmits encrypted 
data with a transmission request specifying a destina- 
tion without caring about an encryption interface with the 
destination (receiver) whereas the transaction manage- 
ment device first decrypts the data using the unique de- 
cryption key shared between the transmitter and the 
transaction management device, and then re-encrypts 
using the unique encryption key shared between the 
specified destination and the transaction management 
device the data into encrypted data which can be de- 
crypted by the destination only. The receiver receives 
the encrypted data from the transaction management 
device : and decrypts the data using the unique decryp- 
tion key shared between the transaction management 
device and the receiver without caring about the encryp- 
tion interface with the source of the encrypted data. 
Therefore, there is no risk that the third party may de- 
crypt the data. 

That is, since the transmitter transmits data encrypt- 
ed using a unique encryption key shared between the 
transaction management device and the transmitter 
without caring about an encryption key or a decryption 
key shared between the transmitter and the destination, 
the transmitter need not transmit or receive any encryp- 
tion or decryption keys to or from any receiver. There- 
fore, it is easy on both transmitting and receiving sides 
to manage an encryption key and a decryption key, and 
no attention should be paid to an encryption method, an 
encryption application interface, etc. , thereby greatly im- 
proving the convenience and safety of data. 

According to the third configuration of the present 
invention, a delivery system includes a seller's process- 
ing unit, a purchaser's or goods receiver's processing 
unit, and a delivery management device provided for a 
goods deliverer The delivery management device in- 
cludes a unit for storing delivery information based on 
the delivery request from the seller's processing unit; 
and a unit for generating the third party delivery certifi- 
cation information containing a receiver's signature and 
a payment ID relating to the purchase of goods. 

With the above described configuration, when a de- 
livery management device receives a delivery request 
from a seller, it manages the receiver's signature at the 
destination and generates the delivery certification in- 
formation containing the payment ID relating to the de- 
livered goods. Therefore, the delivery management de- 
vice can certify the delivery of goods. 

According to the fourth configuration of the present 
invention, the delivery system includes the seller's 
processing unit, the purchaser's or goods receiver's 
processing unit, and the delivery management device 
provided for the goods deliverer. The delivery manage- 
ment device includes a unit for storing return-of-goods 
delivery information at a returned goods delivery re- 



quest from a goods receiver; and a unit for generating 
the first third party return of-goods certification informa- 
tion containing, the signature of the return-of-goods re- 
quester and the payment ID relating to the purchase of 
s goods. 

With the above described configuration, the deliv- 
ery management device manages the signature of a re- 
turn-of-goods requester at a returned goods delivery re- 
quest from a goods receiver, and generates the delivery 
10 certification information containing the payment ID re- 
lating to the goods to be returned. Therefore, the deliv- 
ery management device can certify that the return-of- 
goods process has been started. 

According to the fifth configuration of the present 
invention, the system for selling digital contents includes 
at least a seller's processing unit, a purchaser's 
processing unit, and an intermediating transaction man- 
agement device. The transaction management device 
includes a management unit for managing a decryption 
key for digital contents on behalf of a seller of the digital 
contents; and a unit for sending the decryption key to 
the purchaser's processing unit at a request from the 
purchaser's processing unit. 

With the above described configuration, the trans- 
action management device in the digital contents sales 
system manages a decryption key for the digital con- 
tents on behalf of a seller of the digital contents, and 
sends the decryption key at a request from a purchaser 
of the digital contents. Therefore, the transaction man- 
agement device can correctly manage whether or not 
the digital contents has been successfully transmitted 
to a purchaser. 

According to the sixth configuration of the present 
invention, the transaction management device functions 
as an intermediate with the first party and the second 
party in the data transmission, and includes a unit for 
receiving data using a unique encryption protocol be- 
tween the first party and the transaction management 
device; and a unit for transmitting the received data us- 
ing a unique encryption protocol between the transac- 
tion management device and the second party. 

With the above described configuration, a transac- 
tion is processed through a transaction management 
device. Therefore, a transmitter of transaction informa- 
tion need not request to receive a receiver's encryption 
key or send its own encryption key Additionally, since 
the transmitter transmits data encrypted using a unique 
encryption key shared between the transaction man- 
agement device and the transmitter, the transmitter 
need not transmit or receive any encryption or decryp- 
tion keys to or from any receiver. Therefore, there is no 
risk that the third party may decrypt the transaction in- 
formation. Furthermore, it is easy for the transmitter to 
manage an encryption key, and no attention should be 
paid to an encryption method, an encryption application 
interface, etc., thereby greatly improving the conven- 
ience and safety of data. 

According to the seventh configuration of the 
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present invention, the transaction management device 
for functioning as an intermediate in a provisional set- 
tlement process in which a settlement is made upon re- 
ceipt of a confirmation notification that an object item for 
which payment is to be made has been executed. The 
transaction management device includes a unit for mon- 
itoring a final settlement admission request or a return- 
of-goods request issued by a goods receiver upon re- 
ceipt of goods; and a unit for transmitting the third party 
delivery certification information as authentication infor- 
mation and issues a final settlement admission request 
as a substitute when no final settlement admission re- 
quest or ret urn-of -goods request are issued within a pre- 
determined period. 

With the above described configuration, the trans- 
action management device monitors based on the re- 
ceipt date and time of the goods whether or not the pur- 
chaser has issued a final settlement admission request. 
Therefore, the transaction condition can be correctly un- 
derstood as to whether or not a provisional settlement 
should be switched to the final settlement, the transac- 
tion is to be canceled, etc. 

According to the eighth configuration of the present 
invention, the transaction management device functions 
as an intermediate in a provisional settlement process 
in which a settlement is made upon receipt of a confir- 
mation notification that an object item for which payment 
is to be made has been executed. The transaction man- 
agement device includes a unit for monitoring whether 
or not the seller issues a cancellation request as a result 
of return of goods; and a unit for transmitting the third 
party return-of-goods certification information as au- 
thentication information and issues a cancellation re- 
quest as a substitute when no cancellation requests are 
issued within a predetermined period. 

With the above described configuration, when the 
seller (payee) has to issue a transaction cancellation re- 
quest to the transaction management device after an 
unsuccessful transaction, the transaction management 
device monitors the existence of a transaction cancel- 
lation request process to be performed by the seller, and 
the purchaser or a goods receiver need not check the 
transaction cancellation state. 

According to the ninth configuration of the present 
invention, the transaction management device which 
functions as an intermediate in the sales of digital con- 
tents includes a unit for managing a decryption key to 
the digital contents to be encrypted and transmitted from 
a seller to a purchaser; a unit for transmitting the de- 
cryption key to the purchaser; and a unit for issuing cer- 
tification information of a third-party witness. 

With the above described configuration, the trans- 
action management device in an digital contents sales 
system manages a decryption key to digital contents on 
behalf of a seller of the digital contents, and transmits 
the decryption key at a request of an digital contents 
purchaser. Therefore ! the transaction management de- 
vice can correctly manage the information as to whether 
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or not the digital contents has been successfully trans- 
mitted to the purchaser. 

According to the tenth configuration of the present 
invention, the transaction management device which 
5 functions as an intermediate in the sales of digital con- 
tents includes a unit for determining whether or not the 
data received by a purchaser is defective; a unit for no- 
tifying the purchaser of the defect when it determines 
that the data is defective; and a unit for re-transmitting 
a decryption key to the purchaser when it is determined 
that the decryption key is defective. 

With the above described configuration, the trans- 
action management device in an digital contents sales 
system manages a decryption key to digital contents on 
behalf of a seller of the digital contents, and transmits 
the decryption key at a request of an digital contents 
purchaser. Therefore, the transaction management de- 
vice can correctly manage the information as to whether 
or not the digital contents has been successfully trans- 
mitted to the purchaser. 

According to the eleventh configuration of the 
present invention, the transaction management device 
functions as an intermediate with a delivery manage- 
ment device provided for a goods deliverer, a seller's 
processing unit, and a purchaser's or goods receiver's 
processing unit. The transaction management device 
includes a unit for accepting the entry of the third-party 
delivery certification information of the delivery manage- 
ment device; a unit for accepting the entry of the first 
third-party return-of-goods certification information cer- 
tifying that a ret um-of -goods request has been issued; 
a unit for accepting the entry of the second third-party 
return-of-goods certification information certifying that 
the seller has received the returned goods. 

With the above described configuration, when the 
delivery management device generates the delivery 
certification information certifying that goods have been 
delivered, the return-of-goods certification information 
certifying that the returned goods have been accepted, 
and the final return-of-goods certification information 
certifying that the returned goods have been delivered 
to the seller, all the above mentioned information are en- 
tered in the transaction management device. Therefore, 
the transaction management device can understand ex- 
act situation in each process of a transaction. Further- 
more, trouble with a transaction can be avoided by using 
each piece of the certification information as third-party 
admission information. 

According to the twelfth configuration of the present 
invention, a portable storage medium stores money in- 
formation containing provisional settlement information 
transferred to a payee and settled upon receipt of a con- 
firmation notification informing that an object item for 
which payment is to be made has been executed. 

With the above described configuration, when the 
money information, which contains the provisional set- 
tlement information settled upon receipt of the confirma- 
tion notification that the object item has been executed, 
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is stored in a portable storage medium such as a port- 
able card, etc., a payee can receive payment online 
through a network, etc. when goods are purchased, or 
can receive the payment by directly providing a portable 
storage medium. As a result, the convenience in pay- 
ment can be improved and the opportunities that the 
goods are sold can be extended. 

According to the thirteenth configuration of the 
present invention, a terminal unit connected to a finan- 
cial institution includes a unit for issuing a portable stor- 
age medium storing money information containing the 
provisional settlement information settled upon receipt 
of the confirmation notification that an object item for 
which payment is to be made has been executed. 

With the above described configuration, the porta- 
ble storage medium can be issued from a terminal such 
as an ATM (automatic teller machine), etc. connected 
to an issuing financial institution. As a result, an issue 
of a forged portable storage medium can be sup- 
pressed. 

Furthermore, since a portable storage medium can 
be issued by any terminal unit without designating a spe- 
cific unit, a payer (a person who requests an issue of a 
portable storage medium) can obtain the medium at any 
time when a terminal unit is operable even after the win- 
dows of the issuing financial institution are closed. 

According to the fourteenth configuration of the 
present invention, a terminal unit connected to a finan- 
cial institution includes a unit for transmitting a final set- 
tlement request to the financial institution using a port- 
able storage medium storing money information con- 
taining the provisional settlement information settled up- 
on receipt of the confirmation notification that an object 
item for which payment is to be made has been execut- 
ed. 

With the above described configuration, a payee 
puts the portable storage medium transferred as provi- 
sional settlement money from a payer into the terminal 
unit such as an ATM, etc. connected to the financial in- 
stitution to issue a final settlement request. Therefore, 
even a payee not provided with a sales management 
device connected through a network can process a 
transaction using the provisional settlement system. 

According to the fifteenth configuration of the 
present invention, a terminal unit connected to a finan- 
cial institution includes a unit for automatically collecting 
an inserted portable storage medium after the comple- 
tion of a process if the medium stores collection infor- 
mation. 

With the above described configuration, when a 
portable storage medium is issued from a terminal unit 
such as an ATM, etc. connected to an issuing financial 
institution, it is indicated whether or not an automatic 
collection is performed upon completion of a process. If 
it is indicated that a portable storage medium is auto- 
matically collected, it can be collected upon confirmation 
of completion of a process, thereby avoiding illegal op- 
erations and saving resources by n -using the portable 



storage medium. 

According to the sixteenth configuration of the 
present invention, the delivery management device pro- 
vided for a goods deliverer includes a unit for storing 

s goods delivery information at a goods delivery request 
from a seller, and a unit for generating third-party deliv- 
ery certification information containing a goods receiv- 
er's or substitute's signature certifying the receipt of 
goods and a payment ID relating to the purchase of the 

10 goods when the goods are delivered to the goods re- 
ceiver. 

With the above described configuration, the deliv- 
ery management device which accepts a delivery re- 
quest from a seller manages the receiver's signature at 
is the delivery destination and generates delivery certifi- 
cation information including a payment ID relating to the 
delivered goods, thereby certifies that the goods have 
been delivered. 

According to the seventeenth configuration of the 
present invention, the delivery management device pro- 
vided for a goods deliverer includes a unit for storing 
return -of- goods delivery information at a returned goods 
delivery request from a goods receiver, and a unit for 
generating the first third-party ret urn -of -goods certifica- 
tion information containing the receiver's signature who 
issued a return-of -goods request or a substitute's sig- 
nature and a payment ID relating to the purchase of 
goods. 

With the above described configuration, when the 
delivery management device receives a returned goods 
delivery request from a goods receiver, it manages the 
signature of the requester, generates delivery certifica- 
tion information containing a payment ID relating to the 
goods to be returned, thereby certifying the fact that a 
return-of-goods process has been started. 

According to the eighteenth configuration of the 
present invention, the financial process unit provided for 
a financial institution includes a unit for accepting a re- 
quest for an issue of money information containing the 
provisional settlement information settled upon receipt 
of the confirmation notification that an object item for 
which payment is to be made has been executed, a unit 
for freezing the amount of the money information within 
the balance of the account of the payer, and managing 
the amount as untransferable until the final settlement, 
and a unit for issuing money information containing the 
provisional settlement information. 

With the above described configuration, the finan- 
cial process unit can freeze the amount relating to an 
issue request within the balance of the account of the 
payer. Therefore, the receiver of the money information 
can be credited with the amount of money reserved in 
the financial institution. 

According to the nineteenth configuration of the 
present invention, the financial process unit provided for 
a financial institution includes a unit for receiving a re- 
quest for a transfer regarding provisional settlement 
money from a payee, a unit for confirming whether or 
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not a final settlement request has been issued, a unit for 
transferring money or transferring electronic money to 
a payee based on the contents of the transfer request if 
the final settlement admission has been obtained, and 
a unit for storing request-for-receipt-of -transfer informs- 5 
tion in a database if the final settlement admission has 
not been obtained. 

With the above described configuration, a payee 
need not issue a final settlement request to a financial 
process unit of his or her financial institution. A final set- 
tlement can be quickly made by directly notifying the fi- 
nancial process unit of payer's financial institution of the 
destination (payee's account in the financial institution, 
payee's electronic wallet, etc.) of the transfer of the fi- 
nally settled amount of money. Since a notification about 
the destination of a transfer can be issued with a final 
settlement request, the entire process can be more con- 
veniently performed. Furthermore, the final settlement 
can be automatically made by the financial process unit 
of the financial institution of a payer. 

According to the twentieth configuration of the 
present invention, the financial process unit provided for 
a financial institution includes a unit for accepting a final 
settlement admission request, and a unit for checking 
the validity of the accepted final settlement admission 
request. 

With the above described configuration, the finan- 
cial process unit of the financial institution of the payer 
can quickly and correctly check the validity of the final 
settlement admission request, and automatically per- 
form the final settlement. 

According to the twenty-first configuration of the 
present invention, the financial process unit provided for 
a financial institution includes a unit for accepting a pro- 
visional settlement cancellation request, and a unit for 
checking the validity of the accepted provisional settle- 
ment cancellation request. 

With the above described configuration, the finan- 
cial process unit of a payer can stop the payment ac- 
cording to the money information containing the provi- 
sional settlement information settled upon receipt of the 
confirmation notification that an object item for which 
payment is to be made has been executed if a payer or 
a goods receiver returns goods, or if the object item has 
not been executed. Therefore, the payer or the goods 
receiver can safely cancel a transaction or perform a re- 
turn-of-goods process, etc. 

According to the twenty-second configuration of the 
present invention, the financial process unit provided in 
a financial institution includes a unit for accepting a pro- 
visional settlement cancellation request, a unit for ac- 
cepting a claim to return-of-goods (ret urn -of -goods 
claim), and a unit for reserving the provisional settle- 
ment cancellation request when a return-of-goods claim 
is issued in response to the provisional settlement can- 
cellation request. 

With the above described configuration, a seller can 
reserve a one -direct ion a I provisional settlement cancel- 



lation request by issuing a return-of-goods claim that 
there is a problem with the returned goods (substituted 
goods, damaged goods, shortage in number) if there is 
certainly a problem with the returned goods even if the 
payer or the goods receiver has issued a provisional set- 
tlement cancellation request relating to the return of 
goods through the financial process unit of a payer 

According to the twenty-third configuration of the 
present invention, the payment process unit provided for 
a payer includes a unit for issuing a request to issue 
money information containing provisional settlement in- 
formation settled upon receipt of a confirmation notifica- 
tion that an object item for which payment is to be made 
has been executed. 

With the above described configuration, money in- 
formation containing provisional settlement information 
can be issued through the payment process unit. 

According to the twenty-fourth configuration, the 
payment process unit provided for a payer includes a 
unit for requesting a payee to execute an object item for 
which payment is made; and a unit for transfer to the 
payee the money information containing provisional set- 
tlement information settled upon receipt of a confirma- 
tion notification that the object item for which payment 
is to be made has been executed. 

With the above described configuration, the pay- 
ment process unit can easily order goods, request for 
services, and transfer the money information for pay- 
ment. 

According to the twenty-fifth configuration of the 
present invention, the sales management device in- 
cludes a unit for accepting an order ot goods from a pur- 
chaser of goods, a unit for accepting money information 
containing provisional settlement information from the 
purchaser, and a unit for requesting a final settlement 
after delivering the goods to a goods receiver. 

With the above described configuration, a seller us- 
es the sales management device to confirm that the cost 
of the goods is reserved by a financial institution accord- 
ing to the money information containing provisional set- 
tlement information settled upon receipt of a confirma- 
tion notification that an object item for which payment is 
to be made has been executed. Therefore, goods can 
be safely sold without depending on personal credit. 

According to the twenty-sixth configuration of the 
present invention, the sales management device pro- 
vided for a seller includes a unit for monitoring a final 
settlement admission request or a return-of-goods re- 
quest after a goods receiver receives the goods, and a 
unit for transmitting the third-party delivery certification 
information as authentication information informing that 
the goods receiver has received the goods when the fi- 
nal settlement admission request or the return-of-goods 
request is not issued within a predetermined period, and 
functioning as a substitute for issuing a final settlement 
admission request. 

With the above described configuration, the sales 
management device can issue a final settlement admis- 
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sion request on behalf of a payer on condition that no 
cancellation request or returned goods is received from 
a payer or a goods receiver within a predetermined pe- 
riod, thereby collecting the cost of goods without fail. 

According to the twenty-seventh configuration of 
the present invention, the receipt process unit provided 
for a goods receiver includes a unit for issuing a final 
settlement admission request when goods delivered 
from a seller are accepted based on a receipt confirma- 
tion of the goods. 

With the above described configuration, the receipt 
process unit compares the received goods with the or- 
dered goods, checks the details (manufacturer's name, 
quality, authentication, etc.) of the received goods, and 
the payment can be easily made. 

According to the twenty-eighth configuration of the 
present invention, the payment process unit provided for 
a payer or a confirmor who confirms an object for which 
payment is made includes a unit for monitoring an exe- 
cution term, that is, payment condition information, of 
an object item for which payment is to be made, and a 
unit for issuing a transaction cancellation request after 
transmitting the payment condition information as au- 
thentication information if the object item has not been 
executed within the execution term. 

With the above described configuration, the pay- 
ment process unit can easily issue a transaction cancel- 
lation request if a payer does not execute the object item 
for which payment is to be made within the execution 
term (delivery date of ordered goods, starting date of 
services, etc.). 

According to the twenty-ninth configuration of the 
present invention, the sales management device pro- 
vided for a payee includes a unit for accepting an object 
item for which payment is made from a payer, a unit for 
accepting money information containing provisional set- 
tlement information settled upon receipt of a confirma- 
tion notification that the object item has been executed, 
a unit for monitoring the execution term, which is pay- 
ment condition information of the object item, and a unit 
for notifying a payer or a confirmor, who confirms the 
object item when the object item is not executed within 
the execution term. 

With the above described configuration, the sales 
management device automatically notifies a payer or a 
confirmor, who confirms the object item for which pay- 
ment is made, when the object item is not executed with- 
in the execution term, thereby establishing the mutual 
credit between the payer and the payee. 

Brief Description of the Drawings 

FIG. 1 shows the general configuration of the set- 
tlement system according to the first embodiment 
of the present invention; 

FIG. 2 shows the procedures of the process (settle- 
ment process for provisional settlement money) ac- 
cording to the first embodiment of the present in- 



vention; 

FIG. 3 shows the procedures of the process (settle- 
ment process through provisional payment in set- 
tlement account money) according to the second 
5 embodiment of the present invention; 

FIG. 4 shows the general configuration of the set- 
tlement system according to the third embodiment 
of the present invention; 

FIG. 5 shows the procedures of the process (settle- 
10 ment process for provisional settlement money 
through the transaction management device) ac- 
cording to the third embodiment of the present in- 
vention; 

FIG. 6 shows the procedures of the process (settle- 
f5 ment process for purchase of digital contents) ac- 
cording to the fourth embodiment of the present in- 
vention; 

FIG. 7 shows the procedures of the process (final 
settlement admission request process for the pur- 

20 chase of digital contents) according to the fourth 
embodiment of the present invention; 
FIG. 8 shows the procedures of the process (site 
monitor process for a final settlement admission re- 
quest) according to the fourth embodiment of the 

25 present invention; 

FIG. 9 shows the procedures of the process (can- 
cellation request notification process) according to 
the fourth embodiment of the present invention; 
FIG. 10 shows the procedures of the process (site 

30 monitor process for a cancellation request) accord- 
ing to the fourth embodiment of the present inven- 
tion; 

FIG. 11 shows the general configuration of the set- 
tlement system according to the fifth embodiment 
35 of the present invention; 

FIG. 1 2 shows the procedures of the process (proc- 
ess for a final settlement request from a seller) ac- 
cording to the fifth embodiment of the present in- 
vention; 

40 FIG. 1 3 shows the general configuration of the set- 
tlement system according to the sixth embodiment 
of the present invention; 

FIG. 14 shows the procedures of the process 
(goods purchase process) according to the sixth 

45 embodiment of the present invention; 

FIG. 15 shows the procedures of the process (re- 
turn-of-goods process) according to the sixth em- 
bodiment of the present invention; 
FIG. 16 shows the general configuration of the set- 

50 tlement system according to the seventh embodi- 
ment of the present invention; 
FIG. 17 shows the procedures of the process 
(goods purchase process through the transaction 
management device) according to the seventh em- 

55 bodiment of the present invention; 

FIG. 18 shows the procedures of the process (re- 
turn -of -goods process through the transaction man- 
agement device) according to the seventh embod- 
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iment of the present invention; 
FIG. 19 shows the general configuration of the set- 
tlement system according to the eighth embodiment 
of the present invention; 

FIG. 20 shows the procedures of the process (set- s 
tlement process using a portable storage medium) 
according to the eighth embodiment of the present 
invention; 

FIG. 21 shows the general configuration of an em- 
bodiment of the transaction management device; 10 
FIG. 22 shows the configuration of the databases 
of the transaction management device; 
FIG. 23 shows the configuration of the encryption 
key management database; 

FIG. 24 shows the characteristics of the encryption/ 1$ 
decryption system through the transaction manage- 
ment device; 

FIG. 25 shows the configuration of the transaction 
management database; 

FIG. 26 shows the configuration of a transaction 20 
status; 

FIG. 27A shows the configuration of the final settle- 
ment site monitor database; 
FIG. 27 B shows the configuration of the return -of - 
goods site monitor database; 25 
FIG. 28 is a flowchart showing the procedure of the 
encryption/decryption process; 
FIG. 29 is a flowchart showing the procedure of the 
goods order process. 

FIG. 30 is a flowchart showing the procedure of the 30 
money issue (issue of provisional settlement mon- 
ey) process; 

FIG. 31 is a flowchart showing the procedure of the 
money payment (provisional settlement) process; 
FIG. 32 is a flowchart showing the procedure of the 35 
goods delivery acceptance entry process; 
FIG. 33 is a flowchart showing the procedure of the 
goods delivery receipt entry process; 
FIG. 34 is a flowchart showing the procedure of the 
final settlement request process; 40 
FIG. 35 is a flowchart showing the procedure of the 
final settlement admission request process; 
FIG. 36 is a flowchart showing the procedure of the 
digital contents decryption key acceptance proc- 
ess; 45 
FIG. 37 is a flowchart showing the procedure of the 
digital contents receipt confirmation/cancellation 
process; 

FIG. 38 is a flowchart showing the procedure of the 
provisional settlement cancellation request proc- so 
ess; 

FIG. 39 is a flowchart showing the procedure of the 

digital contents decryption check process; 

FIG. 40 is a flowchart showing the procedure of the 

returned goods delivery acceptance process; ss 

FIG. 41 is a flowchart showing the procedure of the 

returned goods delivery receipt process; 

FIG. 42 is a flowchart showing the provisional set- 



tlement cancellation request acceptance process; 
FIG. 43 is a flowchart showing the return-of-goods 
confirmation/claim acceptance process. 
FIG. 44 is a flowchart showing the procedure of the 
final settlement site monitor process and the forced 
payment process; 

FIG. 45 is a flowchart showing the procedure of the 
return-of-goods site monitor process and the forced 
cancellation process; 

FIG. 46 shows the general configuration according 
to an embodiment of a terminal unit of a financial 
institution; 

FIG. 47 shows the general configuration of a provi- 
sional settlement money card (portable storage me- 
dium) applied to a terminal unit of a financial insti- 
tution and the memory layout of an IC chip; 
FIG. 48 is a flowchart showing the procedure of the 
storage medium issue process; 
FIG. 49 is a flowchart showing the procedure of the 
final settlement admission process; 
FIG. 50 is a flowchart (1 ) showing the procedure of 
the final settlement request process; 
FIG. 51 is a flowchart (2) showing the procedure of 
the final settlement request process; 
FIG. 52 shows the general configuration according 
to an embodiment of the deliverer process unit; 
FIG. 53A shows the configuration of the delivery 
management database; 

FIG. 53B shows the configuration of the delivery re- 
quester information management database and the 
delivery destination information management data- 
base; 

FIG. 54 is a flowchart showing the procedure of the 
delivery acceptance process; 
FIG. 55 is a flowchart showing the procedure of the 
delivery receipt process; 

FIG. 56 is a flowchart showing the procedure of the 

return-of-goods acceptance process; 

FIG. 57 is a flowchart showing the procedure of the 

returned goods receipt process; 

FIG. 58 shows the general configuration according 

to an embodiment of the financial institution 

processing unit; 

FIG. 59 shows the configuration of the databases 
of the financial institution processing unit; 
FIG. 60A shows the configuration of the account 
management database; 

FIG. 60B shows the configuration of the money 
management database; 

FIG. 60C shows the configuration of the provisional 
settlement money management database; 
FIG. 60D shows the configuration of the electronic 
money management database; 
FIG. 60E shows the configuration of the final settle- 
ment information management database; 
FIG. 61 shows the configuration of the return-of- 
goods management database; 
FIG. 62 is a flowchart showing the procedure of the 
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provisional settlement money/electronic money is- 
sue process; 

FIG. 63 is a flowchart showing the procedure of the 

final settlement request acceptance process; 

FIG. 64 is a flowchart showing the procedure of the s 

final settlement admission request acceptance 

process; 

FIG. 65 is a flowchart showing the procedure of the 
provisional settlement cancellation request accept- 
ance process; 10 
FIG. 66 is a flowchart showing the procedure of the 
first third-party ret urn -of -goods certification infor- 
mation acceptance process; 
FIG. 67 is a flowchart showing the procedure of the 
second third-party return-of -goods certification in- 1$ 
formation acceptance process; 
FIG. 68 is a flowchart showing the procedure of the 
ret urn -of -goods claim notification acceptance proc- 
ess; 

FIG. 69 is a flowchart showing the procedure of the 20 
returned goods receipt notification acceptance 
process; 

FIG. 70 is a flowchart showing the procedure of the 
provisional settlement cancellation site monitor 
process; 25 
FIG. 71 shows the general configuration according 
to an embodiment of a purchaser's processing unit; 
FIG. 72 A shows the configuration of the goods pur- 
chase management database; 

FIG. 72B shows the configuration of the money 30 
management database and the provisional settle- 
ment money management database; 
FIG. 72C shows the configuration of the final settle- 
ment admission request management database: 
FIG. 72 D shows the configuration of the return-of- 35 
goods request management database; 
FIG. 73 shows the configuration of the electronic 
money management database; 
FIG. 74 is a flowchart showing the procedure of the 
money information (provisional settlement money) 40 
issue request process; 

FIG. 75 is a flowchart showing the procedure of the 
goods order process; 

FIG. 76 is a flowchart showing the procedures of 
the goods receipt and return -of -goods process; 45 
FIG. 77 shows a general configuration according to 
an embodiment of a seller's processing unit; 
FIG. 78 shows the configuration of the database of 
a seller's processing unit; 

FIG. 79 shows the configuration of the goods man- so 
agement database; 

FIG. 80 shows the configuration of the sales man- 
agement database; 

FIG. 81 A shows the configuration of the provisional 
settlement money management database; 55 
FIG. 81 B shows the configuration of the final settle- 
ment request management database: 
FIG. 82 shows the configuration of the return-of - 



goods management database; 
FIG. 83 shows the configuration of the digital con- 
tents management database; 
FIG. 84 is a flowchart (1 ) showing the procedure of 
the goods order acceptance, money information ac- 
ceptance, and final settlement request process; 
FIG. 85 is a flowchart (2) showing the procedure of 
the goods order acceptance, money information ac- 
ceptance, and final settlement request process; 
FIG. 86 is a flowchart showing the procedure of the 
digital contents transmission process; 
FIG. 87 is a flowchart showing the procedure of the 
final settlement site monitor process; 
FIG. 88 is a flowchart showing the procedure of the 
return-of-goods acceptance process; 
FIG. 89 is a flowchart showing the process of can- 
cellation request acceptance process after return of 
goods of digital contents: 

FIG. 90 is a flowchart showing the procedure of the 

cancellation process after return of goods; 

FIG. 91 is a flowchart (1 ) showing the procedure of 

the execution term monitor process; 

FIG. 92 is a flowchart (2) showing the procedure of 

the execution term monitor process; 

FIG. 93 is a flowchart (1) showing the procedures 

of the execution term monitor and non-execution 

notification process; 

FIG. 94 is a flowchart (2) showing the procedures 
of the execution term monitor and non-execution 
notification process; 

FIG. 95 shows the configuration of an information 

processing device; and 

FIG. 96 shows storage media. 

Description of the Preferred Embodiment 

The preferred embodiments of the present inven- 
tion are described below by referring to FIGs. 1 through 
96. The above described delivery management device 
corresponds to the deliverer's processing unit according 
to the present embodiment. The above described finan- 
cial process unit corresponds to the processing unit of 
the purchaser's financial institution or the processing 
unit of the seller's financial institution. The above de- 
scribed payment process unit corresponds to the pur- 
chaser's processing unit according to the present em- 
bodiment. The above described sales management de- 
vice corresponds to the seller's processing unit accord- 
ing to the present embodiment. If a goods receiver is the 
purchaser, the above described receipt process unit cor- 
responds to the purchaser's processing unit according 
to the present embodiment. 

The preferred embodiment of the present invention 
includes eight embodiments from the first to the eighth 
embodiments. In this specification, the general configu- 
ration and process of the first through eighth embodi- 
ments are briefly explained by referring to FIGs. 1 
through 20. Then, embodiments of the components of 
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the system according to the present invention are de- 
scribed by referring to FIGs. 21 through 96. 

First, the general configuration and the procedure 
of the process according to the first embodiment of the 
present invention is described below by referring to 
FIGs. 1 and 2. 

FIG. 1 shows the configuration of the system ac- 
cording to the first embodiment of the present invention. 
In FIG. 1 , a purchaser's processing unit 1 is provided for 
a purchaser of goods. A seller's processing unit 2 is pro- 
vided for a seller of goods. A processing unit of the pur- 
chaser's financial institution 3 is provided at a financial 
institution in which a purchaser has opened an account. 
A processing unit of the seller's financial institution 4 is 
provided at a financial institution in which a seller has 
opened an account. A financial institution corresponds 
to, for example, a bank. 

The purchaser's processing unit 1 comprises a 
goods management database (hereinafter referred to 
as DB) 1 0 for storing information about goods to be pur- 
chased; a money management DB 1 1 for use in man- 
aging the information about electronic money (money 
information) of a purchaser of goods; and a return-of- 
goods request management DB 12 for use in managing 
a request for return of purchased goods. 

The seller's processing unit 2 comprises a goods 
sales management DB 20 for use in managing the sales 
of goods; a money management DB 21 for use in man- 
aging the information about electronic money received 
from a purchaser; and a return-of-goods management 
DB 22 for use in managing the return of goods from a 
purchaser. 

The processing unit of the purchaser's financial in- 
stitution 3 comprises an account management DB 30 
for use in managing an account of a customer (purchas- 
er) of a financial institution; a provisional settlement 
money management DB 31 for use in managing the pro- 
visional settlement money issued at a request of a cus- 
tomer; a final settlement management DB 32 for use in 
managing the payment process (final settlement) of the 
provisional settlement money issued by the processing 
unit of the purchaser's financial institution 3. 

'Provisional settlement money' refers to electronic 
money (money information containing provisional set- 
tlement information) issued by a financial institution, and 
can be actually credited to a seller's account at a finan- 
cial institution only after a purchaser has confirmed the 
receipt of goods. As described later, a process of, for 
example, confirming the receipt of goods, etc. can be 
performed by a third party on behalf of the purchaser. 

The processing unit of the seller's financial institu- 
tion 4 comprises an account management DB 40 for use 
in managing the account of a customer (seller) in the 
financial institution; and a final settlement execution re- 
quest management DB 41 for use in managing the final 
settlement request of the provisional settlement from the 
customer having an account in the processing unit of 
the seller's financial institution 4. 



The final settlement process according to the first 
embodiment of the present invention is described below 
by referring to the flowchart shown in FIG. 2. In FIG. 2, 
each of the processes performed by the purchaser's 

5 processing unit 1, the seller's processing unit 2, the 
processing unit of the purchaser's financial institution 3, 
and the processing unit of the seller's financial institution 
4 (in order from left column to right column) is represent- 
ed as an item in each column. The process line covering 

10 more than one column indicates the relationship be- 
tween the processes of respective units. For conven- 
ience in explanation, the purchaser's processing unit 1 
can be indicated by (A), the seller's processing unit 2 
can be indicated by (B), the processing unit of the pur- 

fs chaser's financial institution 3 can be indicated by (F1 ), 
and the processing unit of the seller's financial institution 
4 can be indicated by (F2). 

In FIG. 2, the purchaser's processing unit 1 trans- 
mits a goods purchase request to the seller's processing 

20 unit 2 (step 100 (hereinafter referred to as S100)). The 
seller's processing unit 2 which has received a goods 
purchase request checks the stock, sales price, etc. of 
the goods related to the request by searching the goods 
sales management DB 20, and transmits the result to 

25 the purchaser's processing unit 1 (S102). Upon receipt 
of the information about sales price, etc., the purchas- 
er's processing unit 1 stores the information in the goods 
management DB 10. 

The purchaser's processing unit 1 transmits to the 

30 processing unit of the purchaser's financial institution 3 
a provisional settlement money issue request for the 
price of the goods related to the purchase request 
(S104). The purchaser's processing unit 1 simultane- 
ously transmits identification information (detailed pur- 

35 chase information), as a use of provisional settlement 
money, about the goods to be purchased. 

The processing unit of the purchaser's financial in- 
stitution 3 which has received the provisional settlement 
money issue request determines whether or not the pro- 

40 visional settlement money for the specified amount 
(price) can be issued through the account of the pur- 
chaser by referring to the balance information, etc. in 
the account management DB 30. If yes, the amount in 
the balance of the account is frozen and the provisional 

45 settlement money is issued. The provisional settlement 
money is issued by transmitting the provisional settle- 
ment money information to the purchaser after the pro- 
visional settlement money information has been stored 
in the provisional settlement money management DB 31 

50 (S106). 

The provisional settlement money contains amount 
information, issuing financial institution identification in- 
formation, information which identifies the provisional 
settlement money or a corresponding transaction (mon- 
55 ey ID or payment ID hereinafter referred to as payment 
ID), goods identification information which identifies a 
use of provisional settlement money, seller information, 
etc. 
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When the provisional settlement money is issued, 
the processing unit of the purchaser's financial institu- 
tion 3 assigns a blind signature to the important contents 
(amount, goods identification information, seller infor- 
mation) of the provisional settlement money in order to 
avoid an illegal write to the provisional settlement money 
or an illegal use other than a specified use. A blind sig- 
nature relates to a method of encrypting data using a 
private encryption key, which is not open to the public, 
so as not to allow a third party to decrypt the encrypted 
data. When a seller issues a final settlement request to 
the processing unit of the purchaser's financial institu- 
tion 3, the processing unit of the purchaser's financial 
institution 3 decrypts the blind signature using the pri- 
vate decryption key, and compares the contents of the 
blind signature with the corresponding contents of the 
non-encrypted description (plain text) of the provisional 
settlement money. If a person who has received provi- 
sional settlement money with a blind signature has 
changed any of the contents of the blind signature or the 
contents of the non-encrypted description of the provi- 
sional settlement money, then the two contents do not 
match each other, and indicate that the provisional set- 
tlement money has been illegally rewritten. When the 
purchaser's processing unit 1 transmits the provisional 
settlement money to the seller's processing unit 2, it en- 
crypts the un-encrypted description of the provisional 
settlement money, the blind signature, and the authen- 
tication of a financial institution using a common key of 
the purchaser. The seller receives the provisional set- 
tlement money, and decrypts it after obtaining the pur- 
chaser's common key. 

As described above, when the processing unit of 
the purchaser's financial institution 3 issues provisional 
settlement money, it freezes the amount of the issued 
provisional settlement money in the balance of the pur- 
chaser's account. That is, the specified amount is sub- 
tracted from the balance information of the purchaser's 
account in the account management DB 30, and the 
money information of the provisional settlement money 
issued corresponding to the customer's account is 
stored in the provisional settlement money manage- 
ment DB 31 with the information identifying the transac- 
tion (payment ID). The amount information stored in the 
provisional settlement money management DB de- 
scribed later in detail indicates that the provisional set- 
tlement money corresponding to the payment ID can be 
credited to the seller's account when the notification that 
the goods corresponding to the payment ID have been 
delivered to the purchaser (or goods receiver) is re- 
ceived. On the other hand, if the notification that the 
transaction has been canceled due to return of goods 
corresponding to the payment ID is received, the provi- 
sional settlement money corresponding to the payment 
I D is added to the balance of the account of the purchas- 
er in the account management DB 30, and then the pur- 
chaser can use the amount for another use. 

When the purchaser's processing unit 1 receives 



provisional settlement money (including a payment ID, 
identification information of a financial institution, and 
use identification information)(S106), it stores the infor- 
mation about the provisional settlement money in the 
5 money management DB 11. Simultaneously, the pur- 
chaser's processing unit 1 stores the payment ID as- 
signed to the provisional settlement money correspond- 
ing to the goods to be purchased, so that which provi- 
sional settlement money has been used for payment 
10 can be identified. 

Next, the purchaser's processing unit 1 transmits 
the provisional settlement money to the seller's process- 
ing unit 2 (payment of provisional settlement money in 
S108). As described above, the payment ID assigned 
'5 to the provisional settlement money is also transmitted. 
The payment ID can be money ID for use in identifying 
the provisional settlement money by the processing unit 
of the purchaser's financial institution 3, but can be op- 
tionally generated by the purchaser and the seller and 
entered in the processing unit of the purchaser's finan- 
cial institution 3 when the provisional settlement money 
is issued. 

When the seller's processing unit 2 receives the 
provisional settlement money, it checks the legality (va- 
lidity) of the provisional settlement money as follows. 
Assume that the provisional settlement money contains 
as authentication information the un-encrypted descrip- 
tion of financial institution identification information, a 
message digest function of the financial institution (one- 
directional function such as a hash function, etc.), and 
the digital signature of the authentication station for the 
financial institution identification information. At this 
time, the seller's processing unit 2 first applies a mes- 
sage digest function to the un-encrypted description of 
the financial institution identification information. Then, 
it obtains a public key of the authentication station to 
decrypt the digital signature of the authentication sta- 
tion. Then, the seller's processing unit 2 compares the 
application result of the message digest function with 
the decryption result of the digital signature. If they 
match each other, the provisional settlement money is 
recognized as valid. In addition to the check of the fi- 
nancial institution identification information, the authen- 
tication of the purchaser, the validity of the payment ID, 
etc. can also be checked. If the authentication is 
checked about the purchaser, it is checked in a method 
similar to the method of checking the financial institution 
identification information. If the check result is 'OK', then 
the provisional settlement money information is stored 
in the money management DB 21 , and the correspond- 
ing payment ID is stored in the goods sales manage- 
ment DB 20. 

As another method, as shown in Fl Gs. 3 and 1 4 de- 
scribed later, the validity of the provisional settlement 
money can be confirmed by the financial institution us- 
ing the identification information about the financial in- 
stitution and the payment I D contained in the provisional 
settlement money before the transmission of goods (up- 
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on receipt of the provisional settlement money). At this 
time, the identification information about the goods to 
be sold is transmitted to the financial institution to have 
the validity of its use checked in order to detect an illegal 
copy of the provisional settlement money. 

Then, the seller's processing unit 2 instructs the 
transmission of goods (S110). If there is provisional set- 
tlement money corresponding to the transmission of the 
goods, then a final settlement execution request is is- 
sued to the processing unit of the seller's financial insti- 
tution 4 containing the seller's account relating to the 
corresponding provisional settlement money (S112). 
This execution request refers to a request for a substi- 
tute service of issuing a final settlement request to the 
processing unit of the purchaser's financial institution 3. 
At this time, the account number of the seller and the 
goods list are transmitted with the provisional settlement 
money. It is obvious that the seller's processing unit 2 
can transmit the final settlement request directly to the 
processing unit of the purchaser's financial institution 3 
which has issued the provisional settlement money with- 
out transmitting a final settlement execution request (re- 
quest for a substitute service) to the processing unit of 
the seller's financial institution 4. 

When the processing unit of the seller's financial in- 
stitution 4 receives from the seller's processing unit 2 a 
final settlement execution request for the provisional 
settlement money, it stores the information about the re- 
ceived final settlement execution request in the final set- 
tlement execution request management DB41 together 
with the account information according to which pay- 
ment is performed, and transmits to the processing unit 
of the financial institution which has issued the provi- 
sional settlement money (processing unit of the pur- 
chaser's financial institution 3) the final settlement re- 
quest with the specified account to which the amount is 
credited (S114). 

When goods are transmitted to (or received by) a 
purchaser, the purchaser checks the received goods. 

If the goods are what the purchaser has ordered 
(OK), then the purchaser inputs the information that the 
goods have been confirmed as 'OK*. If the received 
goods are defective and the purchaser is not satisfied 
with them, then, a return-of-goods process is performed 
as shown in FIG. 2. The return-of-goods process is de- 
scribed later in details by referring to FIG. 15, but can 
be summarized as a process of canceling the provision- 
al settlement money to nullify the final settlement and 
restore the account of the purchaser to the balance be- 
fore the provisional settlement. 

When the purchaser's processing unit 1 receives in- 
put information that the goods have been confirmed as 
'OK', it transmits a final settlement admission request 
for the provisional settlement money corresponding to 
the goods to the processing unit of the purchaser's fi- 
nancial institution 3 (S116). The final settlement admis- 
sion request is provided with at least a payment ID for 
use in identifying the provisional settlement money. 



Upon receipt of a final settlement request from a 
seller, the processing unit of the purchaser's financial 
institution 3 checks the validity of the request by, for ex- 
ample, comparing the goods list transmitted together 

$ with the final settlement request with the goods informa- 
tion stored in the provisional settlement money. If the 
check result is 'OK', the final settlement request is stored 
in the final settlement management DB 32. 

Upon receipt of the final settlement admission re- 

10 quest from a purchaser, the processing unit of the pur- 
chaser's financial institution 3 stores the request in the 
final settlement management DB 32. 

When a final settlement request and a final settle- 
ment admission request having the same payment ID 

'5 are entered, the processing unit of the purchaser's fi- 
nancial institution 3 performs a final settlement process 
based on the final settlement request (S120). The final 
settlement process is, for example, to transfer the 
amount of the provisional settlement money if the ac- 

20 count to be credited to is specified. If the transfer of elec- 
tronic money is specified when a final settlement re- 
quest is transmitted from the seller's processing unit 2 
to the processing unit of the purchaser's financial insti- 
tution 3, the electronic money is transmitted to the cor- 

25 responding processing unit (S124). 

The processing unit of the seller's financial institu- 
tion 4 transmits the final settlement request to the 
processing unit of the purchaser's financial institution 3, 
receives the transfer from the processing unit of the pur- 

30 chaser's financial institution 3, updates the account bal- 
ance information corresponding to the account manage- 
ment DB 40, and records the completion of the request- 
ed process in the final settlement execution request 
management DB 41. Then, it notifies the seller's 

35 processing unit 2, which issued a final settlement exe- 
cution request, of the transfer (S 1 22). Thus, the final set- 
tlement is completed. 

According to the above described first embodiment 
of the present invention, the following effects can be ob- 

40 tained. 

First, the settlement is made using the provisional 
settlement money available based on a final settlement 
request. Therefore, neither the seller nor the purchaser 
takes a risk. 

45 That is, the seller can be informed that the purchase 
amount of the goods is frozen and reserved in the finan- 
cial institution of the purchaser by confirming the con- 
tents of the provisional settlement money. Therefore, 
the seller can safely deliver the goods to the purchaser. 

so On the other hand, when the purchaser confirms the 
goods, the settlement can be made by issuing a final 
settlement admission request. As a result, the purchas- 
er is not subject to the risk of receiving undesired goods 
with the price prepaid. 

55 Furthermore, since the information about the pur- 
chase of goods and the provisional settlement money 
information are managed by the database and can be 
used in automatically performing each process, the op- 
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erator (purchaser or seller) is not prompted to input data 
except when an order of goods is issued or confirmed. 
This realizes a safe and easy purchase. 

Next, the process flow according to the second em- 
bodiment is described by referring to FIG. 3. The units 
also involved in the above described first embodiment 
are assigned the same identification numbers, and the 
detailed explanation is omitted here. 

According to the first embodiment of the present in- 
vention, a purchaser issues to the processing unit of the 
purchaser's financial institution 3 a request to issue the 
provisional settlement money each time goods are pur- 
chased. According to the second embodiment of the 
present invention, the configuration is the same as that 
shown in FIG. 1 . However the settlement account mon- 
ey is preliminarily stored in the purchaser's processing 
unit 1 as the electronic money which can be used as if 
it were cash, and can be selectively used as provisional 
settlement money or common electronic money when 
goods are purchased. 

The settlement account money contains amount in- 
formation and is circulated as electronic money How- 
ever, it is issued based on the account of a purchaser, 
and can be credited only after the final settlement is 
made for the account at a valid final settlement request. 

The process flow according to the second embodi- 
ment is described below by referring to FIG. 3. 

First, the purchaser's processing unit 1 transmits a 
final settlement account money issue request for a de- 
sired amount to the processing unit at the purchaser's 
financial institution 3 (S130). 

Upon receipt of the final settlement account money 
issue request, the processing unit at the purchaser's fi- 
nancial institution 3 determines whether or not the final 
settlement account money can be issued from the pur- 
chaser's account for the specified amount (whether or 
not the balance or the creditable amount is enough for 
the issue) by referring to the balance information, etc. 
of the account management DB 30 as in the case of the 
provisional settlement money shown in FIG. 2. If yes, 
the specified amount is subtracted from the balance in- 
formation of the purchaser's account in the account 
management DB 30, and the amount information is 
stored in the settlement account management record in 
the account management DB 30 together with the infor- 
mation (money ID) for identifying the settlement account 
money corresponding to the amount. The settlement ac- 
count money for the amount is transmitted (issued) to 
the purchaser's processing unit 1 (S132). 

Described below is the procedure for purchasing 
goods using the settlement account money. 

First, the purchaser's processing unit 1 storing the 
settlement account money transmits a goods purchase 
request to the seller's processing unit 2 (S140). Upon 
receipt of the goods purchase request, the seller's 
processing unit 2 checks the stock, sales price, etc. of 
the goods by searching the goods sales management 
DB 20 : and transmits the result to the purchaser's 



processing unit 1 (S142). Upon receipt of the goods 
sales prices, etc., the purchaser's processing unit 1 
stores the received information in the goods manage- 
ment DB 10. 

5 The purchaser's processing unit 1 prompts the pur- 
chaser to select and input the method of a payment to 
the seller. For example, the purchaser selects one of the 
following methods. 

10 (1 ) final settlement using settlement account money 
without receipt confirmation 
(2) final settlement using settlement account money 
after receipt confirmation 

'5 Unlike the provisional settlement money according 
to the first embodiment of the present invention, the use 
of the settlement account money is not preliminarily de- 
termined. Therefore, a person who receives the settle- 
ment account money can be actually credited with the 

20 settlement account money only by showing the valid fi- 
nal settlement request and the settlement account mon- 
ey ID to the issuing financial institution (processing unit 
at the purchaser's financial institution 3). The seller is 
allowed to this process according to the above de- 

2S scribed selection (1 ). According to the above described 
selection (2), the first embodiment of the present inven- 
tion can be realized. 

According to the second embodiment of the present 
invention, the above described selection (2), that is, the 

30 process of final settlement using settlement account 
money after receipt confirmation, is described below. 

In this case, the purchaser's processing unit 1 gen- 
erates the settlement account money for the cost of the 
purchased goods according to the settlement account 

35 money information stored in the money management 
DB 11, and subtracts the amount for the purchased 
goods from the balance of the settlement account mon- 
ey. The purchaser's processing unit 1 generates 'provi- 
sional settlement money' by adding to the generated 

40 settlement account money for the cost of the purchased 
goods the identification information indicating that the 
settlement account money is for a provisional settle- 
ment, and the ID added to the money ID (for example, 
the payment ID which is identification information spec- 
ks ifying the transaction), and generates the blind signature 
of the purchaser. The blind signature of the purchaser 
is generated so that the processing unit at the purchas- 
er's financial institution 3 which finally received the set- 
tlement account money can confirm that a valid custom- 

so er issued the money. 

Next, the purchaser's processing unit 1 transmits 
the generated settlement account money to the seller's 
processing unit 2 (S144). 

Upon receipt of the settlement account money, the 

55 seller's processing unit 2 performs a goods delivery 
process and issues a settlement account money final 
settlement request. According to the first embodiment 
(FIG. 2), the seller's processing unit 2 issues a final set- 
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tlement request when or after goods are delivered. How- 
ever, according to the present embodiment, the seller's 
processing unit 2 requests the processing unit at the 
purchaser's financial institution 3 to confirm the validity 
of the received settlement account money, and issues 
a final settlement request in step S146. The final settle- 
ment request contains payee information. For example, 
when the transfer (issue of money) of finally settled mon- 
ey to a specified account in the purchaser's financial in- 
stitution is requested, the information about the account 
is contained. When electronic money is requested, the 
address of the purchaser (address of the purchaser's 
processing unit) can be specified. 

Upon receipt of the request for a validity check of 
the settlement account money and the final settlement 
request, according to the information stored in the ac- 
count management DB 30 and the settlement account 
money, the processing unit at the purchaser's financial 
institution 3 checks the blind signature information of the 
settlement account money to confirm the validity of the 
settlement account money. At this time, for example, the 
blind signature information is decrypted using the de- 
cryption key of the purchaser, and the result is compared 
with the corresponding information. If they match each 
other, the validity of the settlement account money is 
confirmed. The processing unit at the purchaser's finan- 
cial institution 3 authenticates the seller according to the 
personal information about the seller who is a requester 
The method of authentication is similar to the above de- 
scribed method of checking the validity of the provisional 
settlement money. If these check results are acceptable, 
the processing unit at the purchaser's financial institu- 
tion 3 stores the settlement account money and the ac- 
count information about the seller, who is a payee, in the 
final settlement management DB 32, and transmits the 
check result to the seller's processing unit 2 (S148). 

Upon receipt of the above described check result, 
the seller's processing unit 2 stores information required 
in goods sales management if the check result is OK, 
and performs a delivery process of the goods (S150). 

Upon receipt of the goods, the purchaser or the 
goods receiver, who is a third party specified by the pur- 
chaser, confirms the received goods (S151 ), and inputs 
a goods confirmation OK to the purchaser's processing 
unit 1 if the received goods are OK. On the other hand, 
if the goods are defective, control is passed to the return- 
of-goods process described later by referring to FIG. 1 5. 

Then, the purchaser's processing unit 1 transmits a 
final settlement admission request for the settlement ac- 
count money corresponding to the goods whose receipt 
has been confirmed by the purchaser to the processing 
unit at the purchaser's financial institution 3 (S1 52). The 
final settlement admission request contains at least a 
payment ID for identifying the settlement account mon- 
ey. 

Upon receipt of the final settlement admission re- 
quest from the purchaser, the processing unit at the pur- 
chaser's financial institution 3 stores it in the final settle- 



ment management DB 32, and notifies the purchaser's 
processing unit 1 of the result (S154). 

The processing unit at the purchaser's financial in- 
stitution 3 performs the final settlement process based 
5 on the final settlement request when both the final set- 
tlement request and the final settlement admission re- 
quest are entered (S155). If the account of the seller, 
who is a payee, is specified, the amount indicated by 
the money information containing the provisional settle- 
10 ment information is transferred to the account (S156). 
Furthermore, if the transfer of electronic money is spec- 
ified, then the electronic money is transmitted to the cor- 
responding processing unit (S160). 

Upon receipt of the transfer from the processing unit 
'5 at the purchaser's financial institution 3, the processing 
unit at the seller's financial institution 4 storing the ac- 
count of the seller updates the corresponding account 
balance information in the account management DB 40, 
and notifies the seller's processing unit 2 of the transfer 
(S158). 

Thereby the final settlement process according to 
the second embodiment terminates. 

According to the above described configuration, the 
provisional payment can be made by transferring the 
settlement account money preliminarily issued as mon- 
ey information, which includes the provisional settle- 
ment information with a blind signature indicating that 
the payment is made on condition of a final settlement 
admission request. Therefore, the effect similar to that 
obtained according to the first embodiment of the 
present invention can be acquired. 

Furthermore, since the provisional settlement infor- 
mation is endorsed by the blind signature and trans- 
ferred with the settlement account money, an illegal 
write by a third party or an illegal use using an illegal 
copy can be effectively avoided. 

According to the first embodiment of the present in- 
vention, a blind signature of an issuing financial institu- 
tion is added to the provisional settlement money. Ac- 
cording to the second embodiment of the present inven- 
tion, a blind signature of a purchaser is added to the 
settlement account money. In any of the two embodi- 
ments, the blind signatures of the issuing financial insti- 
tution and the purchaser can be used in combination. 

The third embodiment of the present invention is de- 
scribed below by referring to FIGs. 4 and 5. 

The settlement system according to the present 
embodiment comprises a transaction management de- 
vice 5 provided in the transaction management center 
for managing a transaction as shown in FIG. 4. The com- 
ponents similar to those according to the first embodi- 
ment are assigned the same identification numbers, and 
the detailed explanation is omitted here. 

As shown in FIG. 4, the transaction management 
device 5 comprises an encryption key management DB 
50, a purchaser information DB 51, a seller information 
DB 52, a financial institution information DB 53, a seller 
information DB 54, a transaction management DB 55, a 
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final settlement site monitor DB 56, and a return-of- 
goods site monitor DB 57. 

The encryption key management DB 50 stores and 
manages the public keys and the common keys of all 
users who transmit and receive data through the trans- 
action management device 5, the unique common keys 
between a transaction management device and users, 
and the private key of the transaction management de- 
vice. 

The purchaser information DB 51 stores and man- 
ages the purchaser's personal information, a network 
ID, the transaction financial institution information, etc. 
about a purchaser. 

The seller information DB 52 stores and manages 
the seller's personal information, a network ID, the 
transaction financial institution information, etc. about a 
seller. 

The financial institution information DB 53 stores 
and manages the personal information, a network ID, 
etc. of the financial institution which issue electronic 
money, perform a settlement, etc. through the transac- 
tion management device 5. 

The deliverer information DB 54 stores and manag- 
es the personal information, a network ID, etc. of a 
house-to-house deliverer (deliverer of goods) who de- 
livers goods or returned goods. 

In the transaction management DB 55, goods pur- 
chase information, payment information, a settlement 
result, etc. of a purchaser are managed. Also, goods 
sales information, goods delivery information, return-of- 
goods information, cancellation information related to 
the return of goods, etc. are managed in the transaction 
management DB 55. Furthermore managed are the 
third-party delivery certification information, the first 
third-party ret urn -of -goods certification information, and 
the second third-party return-of-goods certification in- 
formation from a deliverer as described later. 

The final settlement site monitor DB 56 monitors 
whether or not a purchaser or a goods receiver issues 
a final settlement admission request or a return-of- 
goods request within a predetermined time upon receipt 
of goods. 

The return-of-goods site monitor DB 57 is used to 
perform a monitor process of the state of the issue of a 
return-of-goods request from a goods receiver or a pur- 
chaser, the substitution of a cancellation request proc- 
ess related to the issue of the return-of-goods request, 
a site monitor of the cancellation process of the seller, 
a monitor of the claim state of return -of-goods from a 
seller, etc. 

The detailed configuration of the transaction man- 
agement device 5 is explained after describing the proc- 
esses according to the third through eighth embodi- 
ments. 

FIG. 5 shows the process flow of the final settlement 
performed through the transaction management device 
5. A transmission message is encrypted and decrypted 
in the process according to the present embodiment. To 



simply indicating the encryption and decryption, the pur- 
chaser's processing unit 1 is shown as A; the processing 
unit of the purchaser's financial institution 3 is shown as 
F1; the transaction management device 5 is shown as 
s TC; the processing unit of the seller's financial institution 
4 is shown as F2; and the seller's processing unit 2 is 
shown as B. 

For example, in the goods purchase request in step 
170 (S170), the description 'encryption A-TC indicates 

10 that the purchaser's processing unit A encrypts a mes- 
sage using an encryption key for the transaction man- 
agement device TC, and the transaction management 
device TC decrypts the message using a decryption key 
for the purchaser's processing unit A. The word 'encryp- 
ts tion' includes digital authentication, and an encryption 
using a common key for the purchaser's processing unit 
A of the transaction management device TC. Further- 
more, it also includes an encryption using a combination 
of a plurality of keys and an encryption using a message 

20 digest function. That is, the message is encrypted in 
such a way that it can be decrypted (or confirmed) only 
by a receiver of the message. The subsequent process- 
es are described as, for example, A - TC, and the de- 
tailed explanation is omitted here. 

25 According to the third embodiment, information is 
transmitted and received through the transaction man- 
agement device 5 as a rule. That is, the transaction man- 
agement device 5 receives encrypted information from 
a transmitter, decrypts the information using a decryp- 

30 tion key for the transmitter, then re-encrypts the infor- 
mation using an encryption key for the receiver with the 
authentication of the transaction management device 5, 
and transmits it to the receiver. 

For example, when a goods purchase request is 

35 transmitted in step 170, the transaction management 
device 5 receives encrypted goods purchase request in- 
formation, accesses the purchaser information DB 51 to 
authenticate the purchaser, retrieves the decryption key 
for the purchaser from the encryption key management 

40 DB 50, and decrypts the received goods purchase re- 
quest. Then, it stores the goods purchase information 
in the transaction management DB 55, retrieves from 
the encryption key management DB 50 the encryption 
key for the seller who is the receiver of the information, 

4$ and re-encrypts the goods purchase information with 
the authentication of the transaction management de- 
vice 5. In step 172, the re-encrypted goods purchase 
information is transmitted to the seller's processing unit 
2. 

50 Thus, the transaction management device 5 always 
functions as an intermediate when information is trans- 
mitted or received, decrypts the received information us- 
ing the decryption key, retrieved from the encryption key 
management DB 50, for the transmitter, and stores the 

55 decrypted information in the transaction management 
DB 55. Simultaneously, it re-encrypts the information 
using the encryption key, retrieved from the encryption 
key management DB, for the receiver, and transmits the 
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re-encrypted information to the receiver. 

The processes S170 through S210 shown in FIG. 
5 are the same as those according to the first embodi- 
ment of the present invention except the transaction 
management device 5 as an intermediate. Therefore, 
the detailed explanation is omitted here. 

With the configuration according to the third embod- 
iment of the present invention, the following effects can 
be obtained. 

First, it is not necessary to exchange encryption and 
decryption keys between the purchaser's processing 
unit 1 and the seller's processing unit 2 by mediating the 
transmission and receipt of information among the 
processing units 1 through 4 by the transaction manage- 
ment device 5. Therefore, the security is improved and 
it is not necessary to generate and change an encryp- 
tion/decryption key for each transaction. 

Second, since the transaction management device 
5 can totally manage the proceedings of transactions, 
the conformity of the transactions can be obtained and 
a problem can be successfully avoided among the 
processing units 1 through 4. 

The fourth embodiment of the present invention is 
described below by referring to FIGs. 6 through 10. 

The system according to the fourth embodiment has 
the configuration similar to that according to the third 
embodiment (FIG. 4), and is different in that digital con- 
tents are processed as objects of transactions, and the 
transaction management device 5 (TC) does not only 
function as an intermediate with the information com- 
munications but also as the third party witness. 

A transaction of digital contents' is referred to as 
opposed to a transaction of goods 1 , that is, a transaction 
of tangible goods. In other words, a transaction of digital 
contents refers to a transaction of intangible goods such 
as software, etc. circulated through a network, and is 
different from the transaction of tangible goods in that 
digital contents can be so easily copied that they cannot 
be objects to be returned. Therefore, according to the 
present embodiment, the transaction management de- 
vice 5 manages the transaction as the third-party wit- 
ness organization. 

According to the present embodiment, unlike the 
above described embodiment, when necessary access 
is not gained from the seller's processing unit 2 (B) or 
the purchaser's processing unit 1 (A) within a predeter- 
mined time during the payment process or the cancel- 
lation process, a settlement process or a cancellation 
process are forced to be performed at the responsibility 
of the transaction management device 5 (TC) as shown 
in FIGs. 8, 9, and 10. 

A normal settlement process is described below by 
referring to FIGs. 6 and 7. 

In the present embodiment, the explanation about 
the process of issuing provisional settlement money is 
omitted. The provisional settlement money can be that 
in the first embodiment of the present invention, or the 
settlement account money in the second embodiment. 



The processes similar to those in the above described 
embodiments are omitted here. In the present embodi- 
ment, the transaction management device 5 decrypts 
and re-encrypts information, but the detailed explana- 

5 tion is omitted here. 

First, the purchaser's processing unit 1 transmits an 
order of goods and the provisional settlement money to 
the transaction management device 5 (S220). Then, the 
transaction management device 5 enters the goods pur- 

10 chase information and the provisional settlement money 
information in the transaction management DB 55, and 
re-encrypts and transmits the information to the seller's 
processing unit 2 (S222). The seller's processing unit 2 
accesses the goods sales management DB 20, con- 
's firms the stock, retrieves digital contents, and transmits 
them to the purchaser's processing unit 1 (S224). The 
transmitted digital contents include 'digest' and 'con- 
tents'. A digest is a trial version or an introductory ver- 
sion of contents. According to the digest, the purchaser 

20 is generally informed of the contents. The digest is trans- 
mitted without encryption. The contents, that is, the body 
of the digital contents, are encrypted using a different 
encryption key for each purchaser. Unless there is a dif- 
ferent contents decryption key provided from the seller 

2$ for each purchaser, the contents cannot be accessed. 
Furthermore, an illegal copy can be easily traced by 
printing, into a plurality of portions of the contents, sell- 
er's different blind signatures for respective purchasers. 
The seller's processing unit 2 transmits the contents 

30 decryption key to the transaction management device 5 
in step 226. The transaction management device 5 
stores the key information as transaction information in 
the transaction management DB 55. 

Upon receipt of the digital contents, the purchaser 

35 checks the digest (S225). If the purchaser likes the di- 
gest, he or she issues a request for the contents decryp- 
tion key (S234) to the transaction management device 
5. Thus, through a request from the purchaser's 
processing unit 1 for the contents decryption key, the 

40 purchaser's intention to pay for the contents can be ex- 
pressed. The transaction management device 5 can be 
the witness (third-party witness) by entering the request 
in the transaction management DB 55. 

Next, the transaction management device 5 trans- 

45 mits the contents decryption key to the purchaser's 
processing unit 1 (S236). The purchaser's processing 
unit 1 decrypts the contents using the contents decryp- 
tion key. If the contents can be successfully decrypted, 
the final settlement admission request process shown 

so in FIG. 7 is performed (S241 ). If the contents cannot be 
successfully decrypted, they are transmitted to the 
transaction management device 5 with a cancellation 
request (S240). The transaction management device 5 
issues a request for digital contents to the seller's 

55 processing unit 2 to confirm whether or not the digital 
contents can be decrypted at a cancellation request 
(S242). In response to the request, the seller's process- 
ing unit 2 transmits the encrypted digital contents to the 
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transaction management device 5 (S244). Then, the 
transaction management device 5 tries to decrypt the 
encrypted contents using the contents decryption key is 
the device 5. If the contents can be decrypted, the de- 
cryption key is transmitted to the purchaser's processing s 
unit 1 (S246) again. If the contents cannot be decrypted, 
a cancellation acceptance notification is transmitted to 
the purchaser's processing unit 1 (S248). 

The final settlement admission process (S241) is 
described below by referring to FIG. 7. w 

In the payment process, the purchaser's processing 
unit 1 first transmits a final settlement admission request 
to the transaction management device 5 (S250). The 
transaction management device 5 enters it in the trans- 
action management DB 55 and transmits the final set- '5 
tlement admission request to the processing unit of the 
purchaser's financial institution 3 with the authentication 
of the purchaser (A) (S252). The authentication of the 
purchaser refers to the information indicating that the 
transaction management device 5 has confirmed the 20 
purchaser information. 

The processing unit of the purchaser's financial in- 
stitution 3 confirms, through the provisional settlement 
money management DB 31 , whether or not it has re- 
ceived a final settlement request (execution request) 25 
from the seller's processing unit 2 (S253). If the process- 
ing unit of the purchaser's financial institution 3 has al- 
ready received the final settlement request from the sell- 
er, the processing unit of the purchaser's financial insti- 
tution 3 performs a final settlement by transferring re- 30 
quired money to the processing unit of the seller's finan- 
cial institution 4 (S254), and the processing unit of the 
seller's financial institution 4 transmits the transfer noti- 
fication to the seller's processing unit 2 (S258). 

If the final settlement request has not been entered, 35 
then the processing unit of the purchaser's financial in- 
stitution 3 transmits a demand notification of the final 
settlement request to the transaction management de- 
vice 5 (S260). According to the notification, the transac- 
tion management device 5 transmits a demand for the 40 
final settlement request to the seller's processing unit 2 
(S262). In response to the demand, the seller's process- 
ing unit 2 transmits the final settlement request to the 
transaction management device 5 (S264), and the 
transaction management device 5 transmits the final 45 
settlement request containing a request for receipt of 
transfer to the processing unit of the purchaser's finan- 
cial institution 3 with authentication of the seller (B) 
(S266). As a result, the processing unit of the purchas- 
er's financial institution 3 transfers money in the final set- so 
tlement process as described above if the condition of 
the final settlement is satisfied (S254). If the condition 
is not satisfied, the result is transmitted to the seller's 
processing unit 2 through the transaction management 
device 5 (S268 and S270). 55 

The process of monitoring the payment process site 
is described by referring to FIG. 8. The site monitor in- 
dicates the monitor of the term. According to the present 



embodiment, the transaction management device 5 
forcefully performs the payment process as a third-party 
witness organization if the purchaser does not perform 
a necessary payment process (a final settlement admis- 
sion request) within a predetermined term. 

Therefore, the transaction management device 5 
determines whether or not the payment has been made 
(S280) as shown in FIG. 8. If the payment has not been 
made yet, the payment site monitor is performed (S282). 
As for the term of the payment site monitor, a system 
site monitor term (for example, 7 days) or the site mon- 
itor term in the third-party delivery certification informa- 
tion is set using the receipt date of the goods in the third- 
party delivery certification information or the decryption 
key delivery date as the start point of the term. If the 
payment process shown in FIG. 7 is not performed with- 
in the term, a 'site-over' is determined (S284). Then, the 
transaction management device 5 determines whether 
or not the process is being provisionally settled. If not, 
a payment demand notification is issued to the purchas- 
er's processing unit 1 (S288). If the process is being pro- 
visionally settled, a final settlement admission request 
(request for substitution) and a third-party witness au- 
thentication are transmitted to the processing unit of the 
purchaser's financial institution. 3 (S292). The process- 
ing unit of the purchaser's financial institution 3 assumes 
that the purchaser has issued a final settlement request 
based on the third-party authentication of the transac- 
tion management device 5, and the payment process is 
forcefully performed in the processes (S292 through 
S318) similar to the processes in and after step 252 
shown in FIG. 7. 

The payment site monitor is started from the time 
point (S236) when the transaction management device 
5 transmits the decryption key as shown in FIG. 6. Since 
the fact that the purchaser has received the contents 
and demanded the decryption key is stored in the trans- 
action management DB 55 of the transaction manage- 
ment device 5 (third-party witness), the purchaser can- 
not reject the final settlement admission request. There- 
fore, the transaction management device 5 can perform 
the above described automatic payment process. 

The above described cancellation request notifica- 
tion process is described by referring to FIG. 9. 

The cancellation process is started when the pur- 
chaser does not like the digest of the digital contents 
and transmits a transaction cancellation request to the 
transaction management device 5 (S230). 

As shown in step 330 in FIG. 9, the transaction man- 
agement device 5 transmits a cancellation request no- 
tification to the seller's processing unit 2. Upon receipt 
of the cancellation request notification, the seller's 
processing unit 2 performs the cancellation process. 
First, the seller's processing unit 2 inquires the goods 
sales management DB 20 and the money management 
DB 21 whether or not the cost of the goods has been 
paid (in the case of prepayment) (S332). If the payment 
has been made, the transaction management device 5 
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transmits a transfer request to the transaction manage- 
ment device 5 to return money to the purchaser (S334). 
Upon receipt of the request, the transaction manage- 
ment device 5 inquires the encryption key management 
DB 50, seller information DB 52, financial institution in- 
formation DB 53, transaction management DB 55, and 
ret urn -of -goods site monitor DB 57, and transmits the 
request for receipt of transfer to the processing unit of 
the seller's financial institution 4 with the authentication 
of the seller (B) (S336). 

In response to the request, the processing unit of 
the seller's financial institution 4 accesses the account 
management DB 40, and transfers the predetermined 
amount of money from the account of the seller to the 
purchaser's predetermined account (account manage- 
ment DB 30) in the purchaser's financial institution 
(S340). When the transfer is performed, the processing 
unit of the seller's financial institution 4 notifies the trans- 
action management device 5 of the transfer result, and 
enters the result. 

The processing unit of the purchaser's financial in- 
stitution 3 transmits a transfer notification to the pur- 
chaser's processing unit 1 (S342), thereby terminating 
a refund process. 

On the other hand, if it is determined in step S332 
that the payment has not been made (not prepaid), then 
it is determined whether or not the provisional payment 
has been made, that is, the provisional settlement can 
be applied to the transaction (S344). If it is determined 
that the provisional payment has not been made, that 
is, if the payment is made after or upon receipt of the 
goods, then the seller's processing unit 2 notifies the 
transaction management device 5 of the cancellation 
admission (S346). In this case, since the payment has 
not been made, and the purchaser has not seen the dig- 
ital contents (has not received the goods yet), the pur- 
chaser only has to cancel the transaction. Therefore, af- 
ter the transaction management device 5 has entered 
the cancellation in the predetermined encryption key 
management DB 50, purchaser information DB 51 , sell- 
er information DB 52, and transaction management DB 
55, the transaction management device 5 transmits a 
cancellation completion notification to the purchaser's 
processing unit 1 (S348). 

If it is determined that the provisional payment has 
been made in the process in step S332, that is, if the 
payment is made using provisional settlement money, 
then the seller's processing unit 2 transmits a provision- 
al settlement cancellation request to the transaction 
management device 5 (S350). The transaction manage- 
ment device 5 enters this request in the predetermined 
DBs 50, 52, 53, and 55, and transmits the provisional 
settlement cancellation request to the processing unit at 
the purchaser's financial institution 3 with the authenti- 
cation of the seller (B) (S352). On the other hand, the 
transaction management device 5 determines whether 
or not the final settlement execution request has been 
received from the seller's processing unit 2 (S362). If 



yes, the transaction management device 5 cancels the 
request and notifies the processing unit at the seller's 
financial institution 4 of the cancellation. 

Next, the processing unit at the purchaser's finan- 

5 cial institution 3 determines in step 354 whether or not 
a final settlement request (or final settlement admission 
request) has been received. If yes, the processing unit 
at the purchaser's financial institution 3 cancels the re- 
quest transmits a provisional settlement cancellation 

10 completion notification to the purchaser's processing 
unit 1 (S360), and transmits a final settlement request 
cancellation completion notification to the seller's 
processing unit 2 through the transaction management 
device 5 (S356 and S358). 

>5 The site monitor process in the cancellation process 
is described by referring to FIG. 10. 

The site monitor process in the cancellation process 
is performed when the seller's processing unit 2 does 
not perform any process (S334, S346, or S350) for can- 

20 cellation although a cancellation request notification has 
been received from the transaction management device 
5 (S330) as shown in FIG. 9. Therefore, the site monitor 
is started when the cancellation request notification is 
issued in step 330 as shown in FIG. 9. 

25 As shown in FIG. 10 : the transaction management 
device 5 first determines whether or not it has received 
a cancellation process substitution request (S380). If 
yes, the transaction management device 5 independ- 
ently performs the cancellation process in and after step 

30 386 without the site monitor and regardless of the noti- 
fication from the seller's processing unit 2. 

The cancellation process is the same as the proc- 
ess in and after step 332 shown in FIG. 9 except that 
the transaction management device 5 determines in 

35 steps 386 and 398 respectively as shown in FIG. 10 
whether or not the payment has been made and whether 
or not the provisional settlement has been made, which 
are determined in S332 and S344 respectively by the 
seller's processing unit 2 as shown in FIG. 9. Therefore, 

40 the detailed explanation is omitted here. 

Thus, the process can be performed without a sell- 
er's confirmation because the transaction management 
device 5 can certify as a third-party witness that the pur- 
chaser's processing unit 1 has not received a digital con- 

45 tents decryption key and does not intend to purchase 
the digital contents, and because the transaction man- 
agement device 5 stores all records of the transaction. 
Therefore, the transaction management device 5 can 
quickly and exactly perform a cancellation process by 

50 functioning as a third-party witness regardless of the 
current intention of the purchaser. 

On the other hand, if the cancellation process sub- 
stitution request is not received, the transaction man- 
agement device 5 performs the site monitor in steps 382 

55 and 384, and determines a 'site over' as long as the sell- 
er's processing unit 2 does not perform the process 
shown in FIG. 9 within a monitor term, and performs the 
cancellation process in and after step 386 without a con- 
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firmation of the seller's processing unit 2. 

With the above described configuration, the follow- 
ing effect can be obtained. 

First, since the transaction management device 5 
mediates a transaction, the effect obtained with the third 5 
embodiment can be realized. 

Second, when digital contents are processed, the 
transmission of provisional settlement money and a de- 
cryption key of the digital contents are mediated and 
managed. Therefore, the transaction management de- 10 
vice 5 certifies the transmission processes as a third- 
party witness organization. As a result, processes can 
be automatically performed according to the information 
stored in the transaction management DB 55 even if a 
seller or a purchaser does not take necessary proce- *s 
dures within a predetermined period. Therefore, a trans- 
action settlement process can be performed easily, 
safely, quickly and certainly. 

The fifth embodiment is described by referring to 
FIGs. 11 and 12. 20 

According to the fourth embodiment of the present 
invention, when a transaction of electronic contents is 
performed, the transaction management device 5 is 
used as the third-party witness. However, the fifth em- 
bodiment refers to a system for distribution of physical 25 
goods, and includes a deliverer's processing unit 6 (de- 
livery management device) provided at a house-to- 
house delivery agent, etc. as a third-party witness or- 
ganization. 

As shown in FIG. 1 1 , the deliverer's processing unit 30 
6 comprises a delivery management DB 60. Since other 
components are similar to those according to the first 
embodiment, the explanation of them is omitted. The op- 
erations of the system is described below by referring 
to FIG. 12. 35 

First, assume that the seller's processing unit 2 has 
received an order from the purchaser's processing unit 
1. That is, the seller's processing unit 2 has received 
provisional settlement money and goods purchase in- 
formation from the purchaser's processing unit 1 . In this 40 
case, the seller's processing unit 2 first transmits a 
goods delivery request to the deliverer's processing unit 
6 (S422). The deliverer's processing unit 6 enters goods 
delivery information in the delivery management DB 60, 
and delivers requested goods to the purchaser or a re- 45 
ceiver A specified by the purchaser (S424). 

The deliverer's processing unit 6 receives a receipt 
certificate containing authentication from the purchas- 
er's processing unit 1 (S426), and enters the certificate 
in the delivery management DB 60 together with the de- so 
livery date. The deliverer's processing unit 6 transmits 
delivery result receives a receipt certification including 
authentication from the purchaser's processing unit 1 
(S426), and enters the delivery management DB 60 with 
the delivery date. The deliverer's processing unit 6 55 
transmits the delivery result report information to the 
seller's processing unit 2 (S428). The delivery result re- 
port information contains the receipt certification of the 



purchaser's processing unit 1 and the authentication of 
the deliverer's processing unit 6. These pieces of infor- 
mation are entered in the goods sales management DB 
20 and 21 of the seller's processing unit 2. 

Then, the seller's processing unit 2 determines 
whether or not a final settlement request has been is- 
sued (S430). If it has not been issued yet, a unit to which 
the final settlement request is issued is determined in 
step 432. The final settlement request destination can 
be either (a) the processing unit of the seller's financial 
institution 4, or (b) the processing unit of the purchaser's 
financial institution 3. Since the processes of the final 
settlement execution request (S434 through S440, 
S442 through 446) are similar to the above described 
processes of the final settlement request, the detailed 
explanation is omitted here. 

On the other hand, after the seller's processing unit 
2 has issued the final settlement execution request, it 
starts the site monitor for the final settlement admission 
request (S448 through S452). The site monitor is per- 
formed to forcefully execute the final settlement if the 
final settlement execution request has been issued but 
the transfer of money has not been confirmed, or if no 
return -of-goods process has been performed. A reason- 
able number of days is set as a monitor term required 
from an execution request to a transfer of money. 

If the monitor term has passed without a final set- 
tlement completion notification (S450), the seller's 
processing unit 2 forcefully starts the final settlement ad- 
mission request process as a result of a 'site over* 
(S452). The final settlement admission request process 
is performed based on the fact that the house-to-house 
deliverer (deliverer's processing unit 6) functions as a 
third-party witness organization for certifying the deliv- 
ery of goods, and a purchaser cannot deny his or her 
intention of purchasing the goods unless the purchaser 
returns the goods. 

Therefore, the seller's processing unit 2 transmits 
the final settlement admission request with the third-par- 
ty certification (house-to-house-delivery certification of 
the deliverer's processing unit 6) to the processing unit 
of the purchaser's financial institution 3. The processing 
unit of the purchaser's financial institution 3 checks that 
the request is issued with the third-party certification 
(S456). If the request is recognized as valid, then the 
destination of the transfer is determined in step 462. 
When transfer is addressed to the seller's financial in- 
stitution, money is transferred to the account of the seller 
B in the seller's financial institution (S464). If money has 
been transferred, the processing unit of the seller's fi- 
nancial institution 4 notifies the seller's processing unit 
2 of the transfer (S466). 

On the other hand, if money is transferred to the 
seller's processing unit 2, then the processing unit of the 
purchaser's financial institution 3 transmits electronic 
money to the seller's processing unit 2 (S468), thereby 
terminating the final settlement. 

With the above described configuration, a third-par- 
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ty witness organization other than the seller and the pur- 
chaser exists as in the fourth embodiment of the present 
invention, and the authentication data can be added to 
the provisional settlement money. Therefore, the settle- 
ment process can be performed through the third-party 
certification even if the purchaser does not issue a final 
settlement admission request. Therefore, the settle- 
ment process can be performed quickly and definitely. 

The sixth embodiment of the present invention is 
described below by referring to FIGs. 1 3 through 1 5. 

The system according to the fifth embodiment com- 
prises the deliverer's processing unit 6 for delivering 
goods to a purchaser, whereas the system according to 
the present embodiment further comprises a deliverer's 
processing unit 7 for delivering returned goods as 
shown in FIG. 1 3. The deliverer's processing unit 7 also 
comprises a delivery management DB 70. 

FIG. 14 shows a normal settlement process. FIG. 
15 shows a ret urn-of -goods process. In FIG. 14, the de- 
liverer's processing unit 7 for returning goods does not 
work, but the deliverer's processing unit 6 for delivering 
goods works. 

First, purchaser's processing unit 1 transmits a 
goods order request and provisional settlement money 
to the seller's processing unit 2 (S480). Based on them, 
the seller's processing unit 2 confirms the stock in the 
goods sales management DB 20. If there is no stock, 
then the result is transmitted (returned) to the purchas- 
er's processing unit 1 together with the received provi- 
sional settlement money (S482). If there is any stock, 
the notification is transmitted to the purchaser's 
processing unit 1 (S484). Then, the seller's processing 
unit 2 transmits a final settlement request (request for 
receipt of transfer) to the processing unit of the purchas- 
er's financial institution 3 (S486). The processing unit of 
the purchaser's financial institution 3 checks the con- 
tents (S488), and notifies the seller's processing unit 2 
of the result (S490). If the check result indicates 'OK', 
the processing unit of the purchaser's financial institu- 
tion 3 notifies the seller's processing unit 2 of the result 
only. However, if the check result indicates 'NG', the re- 
sult is transmitted to the seller's processing unit 2 to- 
gether with the provisional settlement money. If the re- 
sult indicates 'NG', the seller's processing unit 2 returns 
the provisional settlement money regardless of the de- 
livery of goods (S492). 

If the result indicates 'OK', the seller's processing 
unit 2 transmits a goods delivery notification to the pur- 
chaser's processing unit 1 (S494), and transmits a 
goods delivery request to the deliverer's processing unit 
6 (S496). The deliverer's processing unit 6 returns a re- 
ceipt certification (receipt) to the seller's processing unit 
2 (S498). 

On the other hand, based on the delivery request 
received by the deliverer's processing unit 6, the house- 
to-house deliverer delivers the goods to the purchaser 
(S500). The purchaser's processing unit 1 issues a re- 
ceipt certification (S502), and the deliverer's processing 



unit 6 adds deliverer authentication to the receipt certi- 
fication and transmits them to the seller's processing 
unit 2 (S504). 

In step 506, the purchaser confirms a delivered 
5 goods. If the purchaser is satisfied with the goods, he 
or she issues a final settlement admission request to the 
processing unit of the purchaser's financial institution 3 
(S508). Based on the request, the processing unit of the 
purchaser's financial institution 3 transfers the cost of 
the purchased goods to the account of the seller in the 
seller's financial institution (S512). The processing unit 
of the seller's financial institution 4 transmits a transfer 
notification to the seller's processing unit 2 (S514). The 
processing unit of the purchaser's financial institution 3 
transmits the transfer result to the purchaser's process- 
ing unit 1 (S510). 

Thus, the normal settlement process terminates. 
If the purchaser is not satisfied with the goods in 
step S506, then the return-of-goods process shown in 
FIG. 15 is performed. In this return-of-goods process, 
either the deliverer's processing unit 6 for normally de- 
livering goods or the deliverer's processing unit 7 for re- 
turning goods can be used. Described below is the proc- 
ess performed by the deliverer's processing unit 7. 

First, the purchaser's processing unit 1 requests the 
deliverer's processing unit 7 to deliver goods to be re- 
turned (S520), and receives the request receipt certifi- 
cation (receipt) (S522). The deliverer Y delivers the 
goods to be returned to the seller (S524), and receives 
the receipt certification (S526) 

The purchaser's processing unit 1 stores the re- 
turned goods receipt certification (receipt) in the return- 
of-goods request management DB 12, and, based on 
the receipt, transmits a provisional settlement cancella- 
tion request and a returned goods acceptance certifica- 
tion to the processing unit of the purchaser's financial 
institution 3 (S528). The processing unit of the purchas- 
er's financial institution 3 transmits the receipt result to 
the purchaser's processing unit 1 (S530). 

The transaction management device 5 does not im- 
mediately perform a transaction cancellation process, 
but sets the number (X) of days for adjustment (S532), 
and monitors whether or not a claim about the returned 
goods is received from the seller. 

That is, the seller checks the returned goods and 
determines whether the return of goods can be admitted 
or refused (a claim against the return of goods) in step 
538. Then, the seller transmits an admission of the re- 
turn of goods or a claim against the return of goods to 
the processing unit of the purchaser's financial institu- 
tion 3 (S540). 

The processing unit of the purchaser's financial in- 
stitution 3 monitors a claim against the return of goods 
or an admission of the return of goods while the number 
of days for adjustment is decremented by 1 every day 
(S546 through S554). If a return-of-goods claim is is- 
sued, then a claim flag is set ON (S544), and the pur- 
chaser's processing unit 1 is informed of the claim 
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(S542) without releasing the provisional settlement 
process. 

If the number of days for adjustment becomes 0 
without a claim flag set ON (S546), the processing unit 
of the purchaser's financial institution 3 performs a pro- 
visional settlement cancellation process (S558), and no- 
tifies the purchaser's processing unit 1 of the process 
(S556). 

With the configuration, the effect similar to that ob- 
tained in the fifth embodiment can be realized. Addition- 
ally, the number of days for adjustment is set and a claim 
is processed based on the third-party certification of the 
house-to-house deliverer by using the house-to-house 
deliverer Y as a third-party witness organization for re- 
turn of goods. 

The seventh embodiment of the present invention 
is described below by referring to FIGs. 16 through 18. 

The system according to the seventh embodiment 
of the present invention is obtained by designing the 
system according to the sixth embodiment (FIG. 13) in 
such a way that the transaction management device 5 
mediates and manages a transaction as in the third em- 
bodiment as shown in FIG. 16. The components de- 
scribed above are assigned the same numbers and the 
detailed explanation is omitted here. 

The transaction process flow according to the 
present embodiment is described below by referring to 
FIG. 17. 

The purchaser's processing unit 1 transmits a 
goods order request and provisional settlement money 
to the seller's processing unit 2 through the transaction 
management device 5 (S570 and S572). At this time, 
the transaction management device 5 decrypts and re- 
encrypts information and enters the transaction in the 
transaction management DB 55 as described according 
to the third embodiment. 

The seller's processing unit 2 stores the received 
provisional settlement money in the provisional settle- 
ment money management DB 21, accesses goods 
sales management DB 20, to check the stock of the 
goods, and transmits the result notification and a final 
settlement request to the transaction management de- 
vice 5 (S574). The transaction management device 5 
stores them in the transaction management DB 55 and 
transmits only the result notification to the purchaser's 
processing unit 1 (S576). The final settlement request 
is transmitted together with the authentication of the sell- 
er B to the processing unit of the purchaser's financial 
institution 3 (S578). The processing unit of the purchas- 
er's financial institution 3 stores them in the final settle- 
ment management DB 32, and transmits the entry result 
to the transaction management device 5 (S580). 

On the other hand, the seller's processing unit 2 
transmits a goods delivery request to the deliverer's 
processing unit 6 for delivering goods (S582). The de- 
liverer's processing unit 6 transmits the acceptance cer- 
tification (receipt) to the seller's processing unit 2 
(S584). 



The deliverer's processing unit 6 transmits the ac- 
ceptance entry of goods delivery to the transaction man- 
agement device 5 (S586), and delivers the goods to the 
purchaser (S588). Upon receipt of the goods, the pur- 

5 chaser issues receipt certification to the deliverer 
(S590). The deliverer's processing unit 6 enters the re- 
ceipt certification in the delivery management DB 60, 
and transmits the receipt certification together with de- 
liverer authentication to the seller's processing unit 2 

10 (S592). 

On the other hand, upon receipt of the goods, the 
purchaser confirms the goods (S593), and transmits a 
final settlement admission request to the transaction 
management device 5 when the goods are acceptable 
1$ (S594). 

The transaction management device 5 enters a final 
settlement admission request in the transaction man- 
agement DB 55. If the final settlement request has been 
entered, the final settlement admission request is trans- 

20 mitted to the processing unit of the purchaser's financial 
institution 3 together with the authentication of the pur- 
chaser A on condition of the entry (S596). 

Based on them, the processing unit of the purchas- 
er's financial institution 3 transfers money to the account 

2S of the seller in the seller's financial institution (S600), 
and the processing unit at the seller's financial institution 
4 issues a transfer notification to the seller's processing 
unit 2 (S602). When the processing unit at the purchas- 
er's financial institution 3 transfers the money, it issues 

30 a result notification to the purchaser's processing unit 1 
through the transaction management device 5 (S604 
and S606). 

When a purchaser transfers money information 
containing provisional settlement information to a seller 

35 and the goods are delivered to a third party as a goods 
receiver, the personal information about the goods re- 
ceiver is added to the money information containing the 
provisional settlement information containing a payment 
ID. As in the case where a purchaser receives goods, 

40 the goods receiver confirms the receipt of the goods. If 
the result is 'OK', the goods receiver issues a final set- 
tlement admission request according to the payment ID 
and the personal information about the receiver. If the 
confirmation result is 'NG\ the goods receiver issues a 

45 return-of-goods request to the deliverer, transmits the 
first third-party return-of-goods certification information 
received from the deliverer, and requests the cancella- 
tion of the provisional settlement. 

On the other hand, if a purchaser is not satisfied 

so with received goods in step 593, then the return-of- 
goods process shown in FIG. 18 is performed. 

As shown in FIG. 18, the return-of-goods process 
is started by transmitting a returned goods delivery re- 
quest to the deliverer's processing unit 7 for delivering 

ss the goods to be returned from the purchaser's process- 
ing unit 1 (S620). The returned goods delivery request 
is entered in the delivery management DB 70 of the de- 
liverer's processing unit 7, and returned goods accept- 
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ance certification is issued to the purchaser's process- 
ing unit 1 (S622). Simultaneously, the deliverer's 
processing unit 7 accesses the transaction manage- 
ment device 5, and enters the acceptance of the re- 
turned goods delivery request (S624). The acceptance 
of the returned goods delivery request contains the in- 
formation about a purchaser, the details about the pur- 
chase of goods, the information about a seller, and the 
authentication of a deliverer. The deliverer delivers re- 
turned goods to the seller (S626). 

Then, the purchaser's processing unit 1 transmits 
the provisional settlement cancellation request to the 
transaction management device 5 (S628), and the 
transaction management device 5 enters it in the trans- 
action management DB 55. The transaction manage- 
ment device 5 transmits the provisional settlement can- 
cellation request, purchaser authentication, a returnof- 
goods request, and deliverer authentication to the 
processing unit at the purchaser's financial institution 3 
(S630). 

The processing unit at the purchaser's financial in- 
stitution 3 enters these data in the database, and sets 
the number of days X as an adjustment term. The ad- 
justment term is set to monitor a return-of-goods admis- 
sion or a claim against return-of-goods from a seller. If 
a claim against ret urn -of -goods is received during the 
adjustment term, the provisional settlement release 
process described later is suppressed. The adjustment 
term X (number of days) is obtained by adding additional 
days such as the average number of days for delivery 
and the number of allowance days in consideration of 
delivery delay, etc. to the number Y of days normally 
required to check returned goods. The number of days 
for adjustment is computed starting with the day on 
which a return-of-goods request is issued to the deliv- 
erer's processing unit 7. 

The processing unit at the purchaser's financial in- 
stitution 3 notifies the purchaser's processing unit 1 of 
the result through the transaction management device 
5 (S636). On the other hand, a seller issues returned 
goods acceptance certification to a deliverer (S638). 
The deliverer's processing unit 7 notifies the transaction 
management device 5 of the completion of returned 
goods delivery upon receipt of the receipt certification 
(S640). The transaction management device 5 enters it 
in the database, and notifies the processing unit at the 
purchaser's financial institution 3 of the completion 
(S642). 

Since the actual delivery date is given to the 
processing unit at the purchaser's financial institution 3 
at this time point, the processing unit at the purchaser's 
financial institution 3 newly sets the term of the number 
Y of days starting with the delivery date as the above 
described adjustment term. The number Y of days is 
normally required to check goods. Thus, the return of 
goods can be more correctly monitored by newly setting 
the adjustment term. 

Next, the processing unit at the purchaser's finan- 



cial institution 3 enters the result of a return-of-goods 
completion entry in the transaction management device 
5 (S646), and the transaction management device 5 no- 
tifies the purchaser's processing unit 1 of the completion 
s of the return of goods (S648). 

On the other hand, the seller checks the returned 
goods, and determines in step 650 whether or not the 
return of the goods can be admitted. When the return of 
goods is admitted, the seller notifies the processing unit 
10 at the purchaser's financial institution 3 of the admission 
through the transaction management device 5 (S652 
and S654). The processing unit at the purchaser's finan- 
cial institution 3 performs the provisional settlement re- 
lease process (cancellation of freezing the account, 
etc.) according to the notification, and transmits a pro- 
visional settlement release notification to the transaction 
management device 5 (S656). The transaction manage- 
ment device 5 transmits the purchaser's processing unit 
1 of the provisional settlement release notification 
(S658). If the return of goods is not admitted within the 
adjustment term, this process is not performed. 

When the return of goods is not admitted, the sell- 
er's processing unit 2 determines in step 660 whether 
or not there is a claim against the return of goods. If yes, 
the claim against the return of goods is entered in the 
transaction management device 5 (S662). The claim is 
further entered in the delivery management DB 70 of the 
deliverer's processing unit 7, and a return-of-goods 
claim flag is set ON (S666). The notification of the return- 
of-goods claim is transmitted from the transaction man- 
agement device 5 to the purchaser's processing unit 1 
(S668). 

Thus, the return-of-goods process terminates. 
With the above described configuration, the follow- 
ing effects can be obtained. 

That is, according to the present embodiment, the 
transaction management device 5 can collectively man- 
age the proceedings of the transaction of goods to check 
the consistency of the transaction. Additionally, a seller 
or a substitution of transactions can proceed with the 
transaction according to the authentication information 
from a deliverer by using a deliverer Z for delivering 
goods and a deliverer Y for returning goods as the third- 
party witnesses. Therefore, the goods transaction set- 
tlement process can be quickly and certainly performed. 

The eighth embodiment of the present invention is 
described below by referring to FIGs. 19 and 20. 

According to the eighth embodiment of the present 
invention, a magnetic card or an IC card, etc. are used 
as information storage medium used in the transfer of 
provisional settlement money. 

That is, according to the above described first 
through seventh embodiments, the provisional settle- 
ment money is stored as data in the money manage- 
ment DB 11 of the purchaser's processing unit 1, and 
transferred through communications between commu- 
nications devices such as servers, etc. However, the 
provisional settlement money is not limited to this appli- 
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cation, but can be issued as information storage medi- 
um. 

FIG. 19 shows the entire configuration of the sys- 
tem. The component also appearing in the above de- 
scribed embodiment is assigned the same identification 
number and the detailed explanation is omitted here. 

In FIG. 19, terminal units 80 and 81 at a financial 
institution are terminals (ATM terminal units, etc.) con- 
nected online to the processing units at the financial in- 
stitution 3 and 4. A purchaser A accesses the purchas- 
er's processing unit 1 through the terminal unit 80 at the 
financial institution, and receives a provisional settle- 
ment money card 82 issued as a storage medium in 
which the provisional settlement money information is 
stored in a magnetic storage unit. Simultaneously, the 
purchaser receives a final settlement admission request 
card 83, which stores the final settlement admission re- 
quest information, issued through the terminal unit 80 at 
the financial institution. 

The purchaser transmits the provisional settlement 
money card 82 to a seller upon or before receipt of 
goods. The seller applies the provisional settlement 
money card 82 to the terminal unit 81 at the financial 
institution, and inputs authentication information and 
payee information into the terminal unit 81 at the finan- 
cial institution. Then, the terminal unit 81 at the financial 
institution can issue a final settlement request to the 
processing unit at the purchaser's financial institution 3 
and a final settlement execution request to the process- 
ing unit at the seller's financial institution 4. At this time, 
the terminal unit 81 at the financial institution collects 
the provisional settlement money card 82 and issues a 
receipt indicating that the final settlement is executed. 
Thus, an illegal reuse of a card can be avoided by col- 
lecting the provisional settlement money card 82, there- 
by legally reusing the card later on. 

On the other hand, after checking received goods, 
the purchaser transmits a final settlement admission re- 
quest to the processing unit at the purchaser's financial 
institution 3 through the terminal unit 80 at the financial 
institution using the final settlement admission request 
card 83 storing final settlement admission request infor- 
mation. The final settlement admission request card 83 
is also collected by the terminal unit 80 at the financial 
institution for legal reuse. 

Then, the process flow of the system is described 
furthermore in detail by referring to FIG. 20. 

First, the purchaser requests the processing unit at 
the purchaser's financial institution 3 through the termi- 
nal unit 80 at the financial institution to issue a provision- 
al settlement money card (S700). The processing unit 
at the purchaser's financial institution 3 accesses the ac- 
count management DB 30, checks the balance, etc. 
(S710), generates provisional settlement money infor- 
mation in the provisional settlement money manage- 
ment DB 31 , and issues from the terminal unit the pro- 
visional settlement money card 82 storing the informa- 
tion (S720). Practically, the terminal unit 80 stores a 



number of card bases, and a card reader/writer provided 
in the terminal unit 80 enters provisional settlement 
money information in the magnetic recording unit of the 
card base. Then, a card is output and issued to a pur- 
5 chaser. 

Then, the purchaser issues a purchase request to 
the seller, and transmits the provisional settlement mon- 
ey card (S730). After- checking the purchase request 
and the provisional settlement money card 82 (S740), 

10 the seller transmits the goods to the purchaser (S750). 
The purchaser checks the goods (S760). If the purchas- 
er is satisfied with the goods, then the purchaser applies 
the final settlement admission request card 83 to the ter- 
minal unit 80, and transmits a final settlement admission 

is request to the processing unit at the purchaser's finan- 
cial institution 3 (S770). If the processing unit at the pur- 
chaser's financial institution 3 accepts the final settle- 
ment admission request, it is displayed on the terminal 
unit 80 (S780). 

20 On the other hand, after the seller delivers the 
goods, applies the provisional settlement money card 
82 to the terminal unit 81 at the financial institution, and 
inputs the transfer destination of the cost (reservation 
of the destination). The information and the reservation 
of the destination stored in the provisional settlement 
money card are transmitted to the processing unit at the 
purchaser's financial institution 3 (S790). The process- 
ing unit at the purchaser's financial institution 3 access- 
es the provisional settlement money management DB 

30 31 , compares them with the provisional settlement mon- 
ey information to check them (S800), notifies the termi- 
nal unit 81 at the financial institution operated by the sell- 
er (S810), and displays the check result. If the check 
result is OK, the final settlement request is accepted, 

35 and the reservation of the transfer destination is made, 
then the terminal unit 81 automatically collects the pro- 
visional settlement money card 82 as used money 
(S820). If the card has been collected, then the process- 
ing unit at the purchaser's financial institution 3 transfers 

40 money to the processing unit at the seller's financial in- 
stitution 4 (S830), and the processing unit at the seller's 
financial institution 4 issues a transfer notification to the 
seller based on the money transfer (S840). 

In step S850, the processing unit at the purchaser's 

45 financial institution 3 issues a final settlement (payment) 
completion notification to the purchaser. 

In these processes, the normal payment process 
terminates. 

In step S760, if the received goods are not desired 
so goods, the purchaser returns the goods to the seller 
(S860). The seller enters the return of the goods in the 
goods sales management DB 20, and returns the pro- 
visional settlement money card 82 to the purchaser 
(S870). Upon receipt of the provisional settlement mon- 
55 ey card 82, the purchaser applies the provisional settle- 
ment money card 82 to the terminal unit 80 at the finan- 
cial institution and inputs the provisional settlement 
money cancellation process to transmit the message to 
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the processing unit at the purchaser's financial institu- 
tion 3 (S880). Based on this, the processing unit at the 
purchaser's financial institution 3 instructs the terminal 
unit 80 to delete the information written in the card, and 
automatically collects the card (S910). In case of an er- 
ror, an error message is displayed (S900). 

With the above described configuration, even a pur- 
chaser or a seller having no communications devices 
such as servers, etc. can use the electronic provisional 
settlement system. Additionally, since the necessary 
procedure can be followed only by applying the provi- 
sional settlement money card to an ATM : thereby saving 
time-consuming inputting operations for the purchaser 
and seller. 

According to the present embodiment, when the 
purchaser issues a final settlement admission request, 
the purchaser can manually input the final settlement 
admission request into an ATM terminal unit. However, 
since it is necessary to input various information such 
as goods purchase information, etc., the manual input 
is a time-consuming operation. Using the final settle- 
ment admission request card 83, the operation is not 
required, and the final settlement admission request can 
be correctly issued. 

When the purchaser transfers the money informa- 
tion containing the provisional settlement information to 
the seller, and transmits the goods to the third party as 
a goods receiver, the purchaser adds the personal in- 
formation about the goods receiver to the money infor- 
mation containing the provisional settlement information 
including a payment ID. The goods receiver confirms the 
receipt of the goods as in the case where the purchaser 
receives the goods. If the result is 'OK', then the goods 
receiver issues a final settlement admission request ac- 
cording to the payment ID and the personal information 
about the goods receiver. If the confirmation result is 
'NG 1 , the goods receiver issues a return-of-goods re- 
quest to the deliverer, transmits the first third-party re- 
turn-of-goods certification information received from the 
deliverer, and issues a provisional settlement cancella- 
tion request. 

Next, the components of the system according to 
the above described first through eighth embodiments, 
that is, the purchaser's processing unit 1, the seller's 
processing unit 2, the processing unit at the purchaser's 
financial institution 3, the processing unit at the seller's 
financial institution 4, the transaction management de- 
vice 5, the deliverer's processing unit 6, and the deliv- 
erer's processing unit 7 are described below. 

The function of each of the units described below 
may not be used in some of the first through eighth em- 
bodiments, but is used in other embodiments. 

First, the transaction management device 5 is ex- 
plained for convenience. 

The transaction management device 5 mediates 
the information communications among the purchaser's 
processing unit 1, the seller's processing unit 2, the 
processing unit at the purchaser's financial institution 3, 



the processing unit at the seller's financial institution 4, 
the deliverer's processing unit 6, and the deliverer's 
processing unit 7. The transaction management device 
5 has the following functions. 

s First, the transaction management device 5 has the 
function of transmitting and receiving data through the 
unique encryption protocol of each of the transmitter and 
the receiver when it mediates the transmission and re- 
ceipt between the units. 

to Second, when the transaction management device 
5 mediates the provisional settlement process, the 
transaction management device 5 monitors whether or 
not the purchaser issues a final settlement admission 
request or a return-of-goods request within a predeter- 

is mined period. If no respondent processes are per- 
formed, the third-party delivery certification information 
is used as authentication information and the final set- 
tlement admission request is issued by the transaction 
management device 5 as a substitute. 

20 Third, the transaction management device 5 moni- 
tors where or not the seller issues a return-of-goods can- 
cellation request. If the cancellation request is not is- 
sued within a predetermined period, the transaction 
management device 5 uses the third-party return-of- 

25 goods certification information as authentication infor- 
mation, and issues the cancellation request as a substi- 
tute. 

Fourth, when the transaction management device 
5 mediates the transaction of digital contents, the trans- 

30 action management device 5 has the function of man- 
aging the decryption key of the digital contents encrypt- 
ed by the seller's processing unit 2 and transmitted to 
the purchaser's processing unit 1 ; transmitting the de- 
cryption key to the purchaser; and issuing a third-party 

35 witness certification information. 

Fifth, in addition to the fourth function, the transac- 
tion management device 5 has the function of determin- 
ing whether or not the digital contents are defective; no- 
tifying the purchaser's processing unit 1 of the defec- 

40 tiveness when they are defective; and transmitting a de- 
cryption key again to the purchaser when it is defective. 

Sixth, when the transaction management device 5 
mediates the deliverer, the seller (goods delivery re- 
quester), and the purchaser (goods receiver), the trans- 

45 action management device 5 has the function of accept- 
ing the entry of the third-party delivery certification infor- 
mation from the deliverer's processing units 6 and 7-; ac- 
cepting the entry of the first third-party return-of-goods 
certification information certifying that return of goods 

50 has occurred; and accepting the entry of the second 
third-party return-of-goods certification information cer- 
tifying that the seller has received the returned goods. 

To attain the above described functions, the trans- 
action management device 5 is designed as shown in 

55 FIG. 21 . That is, the transaction management device 5 
comprises an operation control unit 1010 for controlling 
the entire system: a communications control unit 1020 
for line-connection to each unit which data is transmitted 
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to or received from; a database control unit 1040 for con- 
trolling each database; a transaction management proc- 
ess unit 1 500 for executing each function of the trans- 
action management device 5; an input/output process 
unit 1030; and a memory (random access memory) 
1050. 

The database control unit 1040 manages and con- 
trols the encryption key management DB 50: the pur- 
chaser information DB 51 (purchaser's processing unit 
information management DB); the seller information DB 
52 (seller's processing unit information management 
DB); the financial institution information DB 53 (financial 
institution' processing unit information management 
DB); the seller information DB 54 (deliverer's processing 
unit information management DB); the transaction man- 
agement DB 55; the final settlement site monitor DB 56; 
and the ret urn -of -goods site monitor DB 57 as shown in 
FIG. 21. 

The configuration of the above described databas- 
es managed and controlled by the database control unit 
1040 is shown in FIG. 22. 

That is, the purchaser information DB 51 , the seller 
information DB 52, the financial institution information 
DB 53, and the deliverer information DB 54 manages 
the necessary information such as an ID, a network ad- 
dress, the transmission/receipt protocol, etc. required in 
transmitting/receiving data to and from the un its such as 
the purchaser's processing unit 1 t the seller's process- 
ing unit 2, the processing unit at the financial institution 
3 and 4, the deliverer's processing units 6 and 7. 

The encryption key management DB 50 manages 
an encryption key and an encryption protocol specific to 
each unit used in transmitting and receiving data to and 
from each unit. Encryption keys 1110, 1120, 1130, 1140, 
and 1150 for each unit are referred to through the at- 
tribute information indicated by each unit information 
stored in the purchaser information DB 51 , the seller in- 
formation DB 52, the financial institution information DB 
53, and the seller information DB 54. 

Furthermore, the transaction management DB 55 
stores the contents of each transaction, the proceedings 
of the transaction, and the authentication information 
based on which the transaction is processed. That is, it 
stores goods order information 1 330, payment manage- 
ment information 1340, delivery management informa- 
tion 1360, and ret urn -of- goods management informa- 
tion 1 370 referred to through a payment ID 1 31 0 and a 
transaction status 1320, as shown in FIG. 22. 

Then, the final settlement site monitor DB 56 is a 
database for use in monitoring a final settlement admis- 
sion request and a return -of- goods request after receipt 
of goods as described above. After receipt of the goods 
delivery certification, the goods order information 1330 
is transferred to a final settlement site monitor DB 1400 
for monitor. 

The return-of-goods site monitor DB 57 is a data- 
base for use in monitoring a cancellation request when 
goods are returned as described above. After receiving 



returned goods, the goods management information 
1 370 is stored as return -of- goods management informa- 
tion for use in return-of-goods site monitoring. 

In the above described information, the encryption 
5 key management DB 50, the transaction management 
DB 55, the final settlement site monitor DB 56, and the 
return-of-goods site monitor DB 57 are described below 
further in detail. 

FIG. 23 shows the configuration of the data stored 
in the encryption key management DB 50. 

An encryption key 1110 of the transaction manage- 
ment device 5 includes an authenticating organization 
certificate 1114 of a transaction management device 
containing a secret key K (S, TC) 1 1 1 2 of the transaction 
management device 5 and a public key K (P, TC). 

A purchaser key 1120, a seller key 1130, a financial 
institution key 1140, and a deliverer key 1150 include a 
device ID 1121, a common key 11 22 for each device ID, 
a device authenticating organization certificate 1 1 23 for 
each device ID, a transmission/receipt-exclusive com- 
mon key 1 1 24 between the transaction management de- 
vice and each device, and a transmission/receipt-exclu- 
sive pair keys 1125 between transaction management 
device and each device as shown in FIG. 23. The trans- 
mission/receipt- exclusive pair keys 1125 contains a 
public key 1 1 26 and a secret key 1 1 27. 

The characteristics of the encryption and decryption 
using the above described encryption keys are de- 
scribed below by referring to FIG. 24. 

First, the background of the encryption and decryp- 
tion according to the present embodiment is described. 

Generally, in a goods order, payment in electronic 
money, transmission of digital contents, transmission, 
transfer, etc. of electronic money through a final settle- 
ment, etc. in the electronic commerce, privacy cannot 
be protected or may be illegally used if an electronic 
message is transmitted or received as a plain text. 

various encryption methods such as a secret key/ 
public key method in which different keys are used for 
encryption and decryption including the RSA (Rivest- 
Shamir-Adleman) method, the DSA (digital signature al- 
gorithm) method, etc., and a common key method in 
which the same key is used for encryption and decryp- 
tion including the DES (data encryption standard) meth- 
od, the FEAL ( fast encryption algorithm) method, etc. 
have been developed. Using the above described meth- 
ods, messages are transmitted after being encrypted so 
that the third parties cannot read them. The current en- 
cryption methods are classified into the following two 
types. 

In the first type of encryption method, a transmitter 
requests to receive a public key which is an encryption 
key of a receiver, or obtains a public key after receiving 
the receiver's authentication certificate so that messag- 
es can be encrypted using the public key. The receiver 
uses his or her own secret key which forms a pair with 
the public key to decrypt the received messages. 

In the second type of encryption method, a trans- 
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mitter encrypts electronic messages using a common 
key which is an encryption key of the transmitter. The 
transmitter also encrypts the transmitter's common key 
using the receiver's public key separately obtained and 
transmits the encrypted key together with the encrypted 
messages so that the receiver can decrypt the encrypt- 
ed messages. The receiver decrypts the encrypted key 
using his or her own secret key to obtain the transmit- 
ter's common key, and decrypts the encrypted messag- 
es using the obtained transmitter's common key. How- 
ever, if the transmitter's common key is preliminarily 
transmitted to the receiver, only the messages are en- 
crypted before transmission using the transmitter's 
common key. 

However, in the above described conventional en- 
crypt methods, when a transmitter encrypts a message 
using his or her common key the transmitter has to pub- 
lish it to another person (receiver). Therefore, the com- 
mon key should be changed each time to avoid an illegal 
use or to protect privacy. If a message is encrypted using 
the receiver's public key, a complicated process of ob- 
taining the receiver's public key should be performed. If 
the transmitter sends second and subsequent messag- 
es to the same receiver, the receiver's public key can be 
managed in the database so that the transmitter does 
not have to obtain again the receiver's public key In this 
case, however, the management file becomes large, 
and no synchronization can be gained if the receiver's 
public key is changed, thereby generating the possibility 
that messages cannot be correctly transmitted to the re- 
ceiver. 

A method of solving the above described problem 
is an encryption/decryption method through the trans- 
action management device 5 according to the present 
invention as shown in FIG. 24. 

In FIG. 24, the symbol representing an encryption 
key is, for example, K (a (P), 7). a indicates the type of 
encryption key, P indicates a public key, S indicates a 
secret key, and C indicates a common key y indicates 
the owner of the encryption key of a. p indicates a user 
of the transaction management device 5 (TC) when the 
owner y is the transaction management device 5 (TC), 
and indicates the transaction management device 5 
(TC) when the owner y is a user of the transaction man- 
agement device 5 (TC). The user has the only and 
unique encryption key to be used in the communications 
with the transaction management device 5, and the key 
is not published to the third party. An encryption key with 
no entry of p can be published if the owner y desires. 

Assume that, in FIG. 24, a transmitter 1200 (A) si- 
multaneously transmits the same electronic message to 
a plurality of receivers 1220 (B) and 1230 (C), or trans- 
mits different electronic messages to respective receiv- 
ers 1 220 (B) and 1 230 (C). In these cases, the transmit- 
ter 1200 (A) encrypts an electronic message containing 
the receiver identification information (receiver's unit ID, 
personal information, etc.) using one of the three types 
of encryption keys entered in the transaction manage- 



ment device 5 (TC) ([1] transmitter's common key K (C, 
A), [2] unique common key K (C(A), TC) between a 
transmitter and the transaction management device 5 
(TC), and [4] unique public key K (P(CT), A) between a 
s transmitter and the transaction management device 5 
(TC)) or [3] the transmitter's secret key K(S, A) for a dig- 
ital signature. Then, the transmitter 1200 (A) transmits 
the encrypted electronic message to a transaction man- 
agement device (TC) 5. At this time, the transmitter 1 200 
(A) need not consider the encryption keys of the receiv- 
ers 1220 (B) and 1230 (C). 

The transaction management device 5 (TC) refers 
to the encryption key management DB 50 according to 
the transmitter's identification information (transmitter's 
device ID, personal information, etc.) in the received 
electronic message, and decrypts the received informa- 
tion by retrieving one of the four types of decryption keys 
for the transmitter 1200 (A) ([1] transmitter's common 
key 1122 K (C, A), [2] unique common key 1124 K (C 
(A) ; TC) between a transmitter and the transaction man- 
agement device 5 (TC), [3] transmitter's public key 1123 
K(P.A), and [4] unique secret key 1127 K (S(TC), A) be- 
tween a transmitter and the transaction management 
device (TC)). 

Then, the transaction management device 5 (TC) 
refers to the encryption key management DB 50 accord- 
ing to the receiver's identification information in the de- 
crypted electronic message, re-encrypts the electronic 
message received from the transmitter 1200 (A) using 
one of the four types of encryption keys for the receiver 
1 220 (B) or the receiver 1 230 (C), and transmits the re- 
encrypted electronic message to the receiver 1220 (B) 
or the receiver 1230 (C). The four types of encryption 
keys are: a receiver's common key K (C, y) ([1]* and [1] 
"); a unique common key K (C(p), TC) between a receiv- 
er and the transaction management device (TC) ([2]' 
and [2]"); a receiver's public key K(P,y) ([3]' and [3]"); 
and a unique public key K (P(TC), y) between the re- 
ceiver and the transaction management device (TC). 
The y and the p indicate B or C. 

Upon receipt of information, the receiver 1220 (B) 
or 1230 (C) refers to the transmitter's identification in- 
formation in the electronic message. If a mediator is the 
transaction management device 5 (TC), the encrypted 
message is decrypted using one of the three ([1]"' a re- 
ceiver's common key K (C, y); [2]"' a unique common 
key K (C(P), TC) between a receiver and the transaction 
management device 5 (TC); and [4]'" a unique secret 
key K (S(TC), y) between the receiver and the transac- 
tion management device (TC)) among the four types of 
encryption keys entered in the transaction management 
device 5 (TC), or [3]"' a receiver's secret key K(S,y). 

Thus, when an encrypted electronic message is 
transmitted and received through the transaction man- 
agement device 5 (TC), the transmitter transmits a mes- 
sage without considering the receiver's encryption key 
and without the possibility that a third party may read 
the message, whereas the receiver can safely receive 
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the message without considering the transmitter's en- 
cryption key. 

Each of the four types of encryption keys/decryption 
keys shown in FIG. 24 is not only independently used, 
but also used in an appropriate combination with other 
encryption keys/decryption keys. For example, a trans- 
mitter (A or TC) can encrypt an electronic message us- 
ing a transmitter's common key K(C, A) or K(C P TC), and 
transmit the encrypted message together with a com- 
mon key encrypted using the unique public key K(P(TC), 
y) (where y is A or B, C) between the transmitter and the 
receiver (TC or B, C). In this case, the receiver decrypts 
the encrypted common key using a secret key, and de- 
crypts the electronic message using the decrypted com- 
mon key. 

To furthermore improve the security of the electron- 
ic message, the transmitter 1200 (A) can also execute 
a digital signature as a part of the authentication of a 
message using the transmitter's secret key K(S,A) ; as- 
sign a blind signature using the transmitter's common 
key K(C,A), and encrypt the entire message using the 
only and unique encryption key K(C(A), TC) or K(P(TC), 
A) between the transmitter and the transaction manage- 
ment device (TC). Thus, the authentication can be cor- 
rectly performed and an illegal use or write can be avoid- 
ed. However, when the transaction management device 
5 (TC) re-encrypts the message and sends it to the re- 
ceiver, the transaction management device 5 (TC) does 
not decrypt the blind signature, but transmits it as 'blind'. 

The configuration of the transaction management 
DB 55 is described below in detail by referring to FIG. 
25. As shown in FIG. 25, the transaction management 
DB 55 stores the payment ID 1 310, the transaction sta- 
tus 1320, the goods order information 1330, the pay- 
ment management information 1 340, the delivery man- 
agement information 1360, and the return-of-goods 
management information 1370. 

The payment ID 1 310 indicates the key of the entire 
records. The payment ID is determined when an order 
of goods is placed between the purchaser and the seller, 
and referred to when information is transmitted in ali 
steps including the subsequent delivery and settlement 
for goods. 

The transaction status 1320 indicates the proceed- 
ing step of a transaction, and is required to check wheth- 
er or not the transaction proceeds with correct steps. 
The transaction status is described later by referring to 
FIG. 26. 

The goods order information 1 330 contains details 
of ordered goods 1 331 , purchaser information 1 332, 
seller information 1 333, an order date and time 1 334, 
and digital contents information 1336 as shown in FIG. 
25. The purchaser information 1 332 and the seller infor- 
mation 1 333 contain their own authentication informa- 
tion. Furthermore, a decryption key 1335 required in the 
sales of digital contents is stored when it is provided 
from the seller. Then, it is managed by the transaction 
management device 5. 



The payment management information 1 340 con- 
tains the money information about provisional settle- 
ment money, etc. that is, a money type 1341, purchas- 
er's financial institution information 1342 (issuing finan- 
s cial institution information), seller's financial institution 
information 1343, an amount of money 1344, an issue 
date and time 1 345, and a provisional settlement date 
and time 1346. It further contains the information about 
the proceedings from the provisional settlement to the 
10 final settlement, that is, the discrimination as to whether 
or not the final settlement request has been issued, 
which is set at the final settlement request from the sell- 
er, and the issue date and time 1 347, a payee 1 348 of 
final settlement, the discrimination as to whether or not 
the purchaser has admitted the final settlement, and the 
admission date and time 1 349, the discrimination as to 
whether or not the final settlement has been completed, 
and the completion date and time 1350. The payment 
management information 1340 further contains the in- 
formation about the proceedings of a provisional settle- 
ment cancellation request through return of goods, that 
is, the discrimination as to whether or not the purchaser 
has issued a provisional settlement cancellation request 
and whether or not it has been processed, and the issue 
date and time 1 351 , the discrimination as to whether or 
not the seller has issued a provisional settlement can- 
cellation request and whether or not it has been proc- 
essed, and the issue date and time 1352, and the dis- 
crimination as to whether or not the provisional settle- 
ment has been canceled, and the cancellation date and 
time 1353. 

The delivery management information 1360 is 
stored and managed when the deliverer's processing 
units 6 and 7 mediate. It contains deliverer information 
1361 and details of delivery 1362 which are necessary 
for delivery, a final settlement site monitor term 1363 in 
which a final settlement admission request and a return- 
of-goods request are monitored after receipt of goods, 
delivery requester information 1364 including the au- 
thentication of a delivery requester, delivered goods re- 
ceipt information (receipt date and time 1365, receipt 
authentication 1366, and third-party delivery certifica- 
tion 1367) including third-party delivery certification 
1367 issued by the deliverer's processing units 6 and 7 
upon receipt of delivered goods. As described above, 
the third-party delivery certification 1367 is used when 
the transaction management device 5 (TC) issues, on 
behalf of the purchaser, a final settlement admission re- 
quest if no final settlement admission request or return- 
of-goods request is issued from the purchaser or the 
goods receiver within a predetermined period after re- 
ceipt of the goods. 

The return-of-goods management information 1 370 
basically stores information similar to the delivery man- 
agement information 1360. In this case, important data 
are a site monitor term 1 373 for a return-of-goods claim 
in monitoring a return-of-goods confirmation/claim after 
receipt of returned goods, first third-party return-of- 
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goods certification 1375 and 1 376 issued by a deliverer 
when a goods receiver issues a ret urn-of -goods re- 
quest, second third-party return -of -goods certification 
1 377 and 1 378 issued by a deliverer when the seller re- 
ceives returned goods, the discrimination as to whether 
or not a ret urn-of -goods confirmation has been issued 
after the seller receives returned goods, and the issue 
date and time 1 379, and the discrimination as to whether 
or not the return-of-goods claim has been issued, and 
the issue date and time 1 380. The first third-party return- 
of-goods certification 1 375 and 1 376, and the second 
third-party return-of-goods certification 1377 and 1378 
are used when a cancellation request is issued on behalf 
of the seller if no retum-of-goods confirmation or return- 
of-goods claim is issued from the seller within a prede- 
termined period after receipt of returned goods. 

The transaction status 1 320 is described below by 
referring to FIG. 26. 

As shown in FIG. 26, the transaction status 1320 
stores the proceedings of each of the processes A. order 
through delivery of goods (A-1 to A-6), B. settlement for 
a normal transaction (B-1, B-2), and C. cancellation at 
return-of-goods (C-1 to C-6). It includes process gener- 
ation date and time 1321 and 1326, a result (OK/NG) 
1322 and 1327, and authentication information 1323 
and 1 328 which is used as evidence. The transaction 
status 1 320 is managed after being divided into a phys- 
ical goods transaction and a digital contents transaction. 

As for the transaction status 1 320, the status chang- 
es in this order Therefore, the transaction management 
device 5 checks the consistency between the transac- 
tion status 1320 and the transmitted data when the 
transaction management device 5 receives the transac- 
tion data from each device in order to avoid a passing- 
over or an accident due to an illegal operation or mis- 
take, thereby performing successful control during the 
processes. 

The configurations of the final settlement site mon- 
itor DB 56 and the return-of-goods site monitor DB 57 
are described below by referring to FIGs. 27A and 27B. 

The final settlement site monitor DB 56 shown in 
FIG. 27A is generated upon receipt of goods as de- 
scribed above, and stores a payment ID 1401, a final 
settlement site monitor term 1402, a discrimination as 
to whether or not a final settlement has been made, and 
the final settlement date and time 1403, and a discrim- 
ination as to whether or not there is a switch to a return- 
of-goods site monitor set when the retum-of-goods oc- 
curs, and the switch date and time 1404. 

The return-of-goods site monitor DB 57 shown in 
FIG. 27B is generated when a return-of-goods request 
is issued as described above, and stores a payment ID 
1421, a return-of-goods site monitor term 1422, and a 
discrimination as to whether or not a provisional settle- 
ment cancellation is issued, and the cancellation date 
and time 1423. 

A transaction management process unit 1500 
shown in FIG. 21 is described below in detail. 



As shown in FIG. 21, the transaction management 
process unit 1500 comprises an encryption/decryption 
process 1520, a goods order process 1600, a money 
issue process 1 700, a money payment process 1740, a 
5 goods delivery acceptance process 1800, a goods de- 
livery receipt process 1820, a final settlement request 
process 1900, a final settlement admission process 
1 960, a digital contents key acceptance process 2000, 
a digital contents receipt confirmation/cancellation proc- 
ess 2100, a returned goods delivery acceptance proc- 
ess 2200, a returned goods delivery receipt process 
2220, a provisional settlement cancellation acceptance 
process 2300, a returned goods confirmation/claim ac- 
ceptance process 2340, a final settlement site monitor 
process 2400, and a return-of-goods site monitor proc- 
ess 2500. 

In the data transmission/receipt, the encryption/de- 
cryption process 1520 decrypts data encrypted by a 
transmitter when it receives the data, and transmits the 
data after encrypting it using an encryption key exclu- 
sively used for a receiver. This process is a common 
process used in the other 1 5 processes. 

Each process from order to deliver of goods is per- 
formed in the processes from the goods order process 
1600 to the goods delivery receipt process 1820. The 
final settlement request process 1900 and the final set- 
tlement admission process 1960 are processes for a 
normal settlement. 

On the other hand, the digital contents key accept- 
ance process 2000 and the digital contents receipt con- 
firmation/cancellation process 2100 are provided for a 
process specific to the sales of digital contents. The 
processes from the returned goods delivery acceptance 
process 2200 to the returned goods confirmation/claim 
acceptance process 2340 are the processes from ac- 
ceptance of return-of-goods to cancellation of settle- 
ment. 

The final settlement site monitor process 2400 is, 
as described above, a process of monitoring a period 
from the delivery of goods to the final settlement or the 
return of goods. The retum-of-goods site monitor proc- 
ess 2500 monitors a period from the occurrence of re- 
turn-of-goods to the cancellation of provisional settle- 
ment. 

Each of the following processes is described below 
by referring to the flow of the processes shown in and 
after FIG. 28. 

First, the encryption/decryption process 1 520 is de- 
scribed by referring to FIG. 28. 

The encryption/decryption process 1520 functions 
in the data transmission/receipt to and from each de- 
vice. If it receives data in step 1522, the transmitter-ex- 
clusive decryption key 1 1 20 is retrieved from the encryp- 
tion key management DB 50 in the transaction manage- 
ment device 5 as described above in step 1524. In step 
1526, the data encrypted using the transmitter-exclu- 
sive encryption key is decrypted using the retrieved key. 
When data is transmitted after a predetermined 



75 



20 



25 



30 



35 



40 



45 



50 



29 



57 



EP 0 858 057 A2 



58 



process is performed, it is determined in step 1528 
whether or not the data should be transmitted. In step 
1530, receiver information is extracted from a receiver 
information management DB such as the seller informa- 
tion DB52, and the transmitter-exclusive encryption key 
1120 is retrieved from the encryption key management 
DB50 in step 1532. In step 1534, the transmission data 
is encrypted using the encryption key 1120. In step 
1 536, the encrypted data is transmitted according to the 
receiver information. 

When a transaction is mediated between two devic- 
es, the transmitter's encrypted electronic message is 
decrypted in the above described procedure, and then 
re-encrypted using the* receiver's encryption key for 
transmission as shown in FIG. 24. 

In the process flow in the transaction management 
process unit 1500, all transmission and receipt process- 
es are performed as the process shown in FIG. 28 in 
principle. 

Then, if a final settlement admission request or a 
ret urn -of -goods request is monitored after receipt of 
goods by a goods receiver, and no such requests have 
been detected within a predetermined period, then the 
third-party delivery certification information is transmit- 
ted as authentication information, and a final settlement 
admission request is issued by a substitute such as the 
goods delivery receipt process 1 820, the digital contents 
receipt confirmation/cancellation process 21 00, the final 
settlement admission process 1 960, the final settlement 
request process 1 900 : and the final settlement site mon- 
itor process 2400. 

These processes are performed based on the third- 
party delivery certification 1 367 contained in the delivery 
management information 1360 in the final settlement 
site monitor DB 56 and the transaction management DB 
55. The third-party delivery certification 1 367 in the final 
settlement site monitor DB 56 and the transaction man- 
agement DB 55 is set in the goods delivery receipt proc- 
ess 1820 for common goods, and in the digital contents 
receipt confirmation/cancellation process 2100 for dig- 
ital contents. 

The process flow in the goods delivery receipt proc- 
ess 1820 is shown in FIG. 33. In the goods delivery re- 
ceipt process 1820, the deliverer's processing unit 6 or 
7 informs that delivered goods are received by a goods 
receiver (a purchaser or a receiver specified by the pur- 
chaser or a substitute) when common goods are deliv- 
ered, and the information is entered. As shown in FIG. 
33, if there is no problem found in a transaction status 
consistency check (step 1824), then the final settlement 
site monitor term 1363 and the delivery receipt informa- 
tion 1365/1366/1367 (the third-party delivery certifica- 
tion by the deliverer's processing units 6 and 7) in the 
delivery management information 1360 in the transac- 
tion management DB 55 are set (step 1828), the final 
settlement site monitor DB 56 is generated (step 1830), 
and stored in the transaction status (step 1832). Using 
the DB 56, it is monitored whether or not a final settle- 



ment request or a ret urn -of -goods request has been is- 
sued. 

In processing digital contents as shown in FIG. 37, 
the final settlement site monitor term 1363 and the de- 

5 livery receipt information 1 365/1 366/1 367 (the third-par- 
ty delivery certification by the transaction management 
device 5) in the delivery management information 1360 
in the transaction management DB 55 can be set when 
a decryption key is transmitted to the purchaser's 

10 processing unit 1 in step 21 1 2 in the digital contents re- 
ceipt confirmation/cancellation process 2100 (the entire 
flow is described later), and a similar monitor can be re- 
alized by generating the final settlement site monitor DB 
56. 

75 Then, a final settlement admission request from a 
goods receiver is processed in the final settlement ad- 
mission process 1 960. 

As shown in FIG. 35, in the final settlement admis- 
sion process 1960 : the data of the final settlement ad- 
20 mission 1 349 of the payment management information 
1 340 in the transaction management DB 55 is set as 
'admitted" in step 1968. Then, in step 1970, a final set- 
tlement admission request is transmitted together with 
the authentication of the receiver to the purchaser's fi- 
25 nancial institution, and the final settlement process is 
performed in the purchaser's financial institution. At this 
time, if the final settlement request (request for receipt 
of transfer which is described in detail later) has been 
issued, the final settlement process terminates. There- 
to fore, in and after step 1980, the data of the final settle- 
ment 1350 in the payment management information 
1 340 in the transaction management DB 55 is updated 
into 'completed', and the transaction status 1320 is up- 
dated into 'B-2 (final settlement) 1 . 
35 Furthermore, the data of the final settlement 1403 
of the final settlement site monitor DB 56 is set to 'com- 
pleted', and the date and time are also set. If the seller 
has not issued a final settlement request (request for 
receipt of transfer), the purchaser's financial institution 
40 returns a demand for a request for receipt of transfer 
which is necessary to perform the final settlement proc- 
ess. Therefore, a notification of a demand for a request 
for receipt of transfer is transmitted to the seller (step 
1988). 

45 The final settlement request process 1900 is de- 
scribed below by referring to FIG. 34. 

After the seller has delivered goods, the final settle- 
ment request process 1 900 functions as an intermediate 
in the process of issuing a request to the purchaser's 
50 financial institution the final settlement (transfer) of the 
provisional settlement money received from the pur- 
chaser. The final settlement request process 1900 is 
processed in the processing unit of the purchaser's fi- 
nancial institution 3 when both the seller's final settle- 
rs ment request and the purchaser's final settlement ad- 
* mission request have been issued according to the 
present embodiment. 

In the process shown in FIG. 34, when a request for 
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receipt of transfer is received from the seller in step 
1902, a consistency check is made between a request 
for receipt of transfer and a transaction status in step 
1 904. To pass the consistency check, the transaction 
status 1320 of the transaction management DB 55 5 
should be one of 'A-4 (accepting delivery)', 'A-5 (receiv- 
ing delivery)', and 'B-1 (final settlement admission)' 
when the third-party witness such as a transaction man- 
agement center in the sales of digital contents, a goods 
deliverer, etc. exists. When no third-party witness exists, 10 
the transaction status 1320 should be one of 'A-3 (pro- 
visional settlement)' and 'B-1 (final settlement admis- 
sion)' 

Since no final settlement admission request has 
been issued in 'A-3 (provisional settlement)', 'A-4 (ac- is 
cepting delivery) 1 , and 'A-5 (receiving delivery), only the 
request for receipt of transfer is accepted (steps 1908 
through 1 91 2). On the other hand, since the final settle- 
ment admission request has been entered in 'B-1 (final 
settlement admission)', the final settlement process re- 20 
quest is transmitted to the purchaser's financial institu- 
tion; and the final settlement process is performed 
(steps 1920 through 1936). 

A return -of -goods request for general goods is ac- 
cepted in the returned goods delivery acceptance proc- 25 
ess 2200 for accepting and entering the delivery of re- 
turn-of-goods from the deliverer's processing unit 7 as 
described later. At this time, the discrimination as to 
whether or not the final settlement site monitor is 
switched to a return-of -goods site monitor, and the date 30 
and time 1 404 are set in the final settlement site monitor 
DB 56, and the return-of-goods site monitor DB 57 is 
generated. Afterwards, the monitor is performed in the 
return -of -goods site monitor process 2500. 

The return of goods for digital contents is accepted 35 
in the digital contents receipt confirmation/cancellation 
process 2100. In the process 2100, a reply is received 
from the purchaser who receives digital contents (step 
2102), and the contents of the request is determined 
(step 2104) as shown in FIG. 37. If the purchaser tries 40 
the digest of the contents and is not satisfied with them, 
a purchase cancellation request is issued and based on 
it the provisional settlement cancellation request proc- 
ess is performed in step 21 40. In this process, as shown 
in FIG. 38, the discrimination as to whether or not a 45 
switch to a return-of-goods site monitor is performed, 
and the date and time are set in the final settlement site 
monitor DB 56, and the return-of-goods site monitor DB 
57 is generated in step 2144. Afterwards, the monitor is 
performed in the return-of-goods site monitor process so 
2500. At this time, a cancellation request notification is 
transmitted to the seller (step 21 52) to demand for a can- 
cellation process through confirmation of return-of- 
goods by the seller. 

The process of monitoring a final settlement admis- 55 
sion request or a return-of-goods request is performed 
by the final settlement site monitor process 2400. As 
shown in FIG. 44, each record of the final settlement site 



monitor DB 56 is periodically read in steps 2402 and 
2404. From the records, a record is extracted in which 
both the final settlement 1403 set as 'settled* and the 
settlement date and time, and the switch to the return- 
of-goods site monitor set as 'yes* and the switch date 
and time are not set, additionally, the final settlement 
admission 1 349 of the corresponding payment manage- 
ment information 1 340 in the transaction management 
DB 55 is not set, and the term set in the final settlement 
site monitor term 1402 expires. Since this record indi- 
cates a transaction for which a final settlement admis- 
sion request or a ret urn -of -goods request has not been 
issued within a predetermined term after receipt of 
goods, a final settlement admission request containing 
the purchaser information 1332, the purchaser's finan- 
cial institution information 1 342, and the amount of mon- 
ey 1 344 of the transaction management DB 55 is trans- 
mitted together with the third-party delivery certification 
1367 of the delivery management information 1360 to 
the purchaser's financial institution on behalf of the re- 
ceiver in step 2406. Then, the financial institution per- 
forms the final settlement process. The transaction sta- 
tus 1320 is changed into 'B-1 (final settlement admis- 
sion) 1 . If the seller has not issued a final settlement re- 
quest (request for receipt of transfer) at this time point, 
the purchaser's financial institution returns a demand for 
a receipt of transfer to the seller because it is necessary 
in the final settlement process. Therefore, a request for 
the demand for receipt of transfer is transmitted to the 
seller (step 2420). 

Then, it is monitored whether or not the seller issues 
a return-of-goods cancellation request, tf a cancellation 
request is not issued within a predetermined period, a 
cancellation request containing the third-party return-of- 
goods certification information is issued by the transac- 
tion management device 5 as a substitute. This process 
is normally performed by the return-of-goods site mon- 
itor process 2500 as explained below. 

The process of issuing a cancellation request as a 
substitute is performed based on the return-of-goods 
site monitor DB 57 and the first third-party return-of- 
goods certification 1 375 and 1 376 and the second third- 
party ret urn -of -goods certification 1 377 and 1 378 stored 
in the return-of-goods management information 1 370 in 
the transaction management DB 55. As described later, 
the return-of-goods site monitor DB 57 and the first third- 
party return-of-goods certification 1375 and 1376 and 
the second third-party return-of-goods certification 1 377 
and 1 378 in the transaction management DB 55 are set 
by the returned goods delivery acceptance process 
2200 and the returned goods delivery receipt process 
2220 for physical goods, and set by the digital contents 
receipt confirmation/cancellation process 2100 for dig- 
ital contents. However, only the first third-party return- 
of-goods certification is used for digital contents. 

In any case, the return-of-goods site monitor term 
1422 is set in the return-of-goods site monitor DB 57. 
Using the return-of-goods site monitor DB 57, it is mon- 
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itored whether or not a cancellation request is issued 
through a return-of-goods admission from the seller 
within a predetermined period. 

The cancellation request through return of goods is 
monitored in the return-of-goods site monitor process 
2500, and the process flow is shown in FIG. 45. In steps 
2502 and 2504 of the process flow, each record in the 
return-of-goods site monitor DB 57 is periodically read. 
From the records, a record is extracted in which both 
the provisional settlement cancellation 1 423 set as 'can- 
celed' and the settlement date and time, and the return- 
of-goods confirmation 1 379 of the corresponding return- 
of-goods management information 1 370 in the transac- 
tion management DB 55 are not set, and the term set in 
the return-of-goods site monitor term 1422 expires. 
Since this record indicates a transaction for which a can- 
cellation request through return-of-goods admission 
has not been issued from the seller within a predeter- 
mined term after goods have been returned. Further- 
more, in step 2506, it is confirmed that no return-of- 
goods claim has been issued by selecting in step 2506 
a record for which the return-of-goods claim 1 380 in the 
return-of-goods management information 1370 in the 
transaction management DB 55 has not been set. 

In this transaction, a cancellation request is trans- 
mitted to the purchaser's financial institution on behalf 
of the seller Since a provisional settlement cancellation 
is made in a provisional payment electronic settlement 
system (step 2508), the transaction status 1 320 in trans- 
action management DB 55 is set as 'C-4 (return-of- 
goods confirmation) 1 , and a final settlement stop instruc- 
tion containing the second third -party return-of-goods 
certification 1378 in the return-of-goods management 
information 1370 (the first third-party return-of-goods 
certification 1376 for digital contents) added to the pay- 
ment management information 1 340 in the transaction 
management DB 55, and a provisional settlement can- 
cellation request are transmitted to the processing unit 
of the purchaser's financial institution 3 on behalf of the 
seller in and after step 2510. Thus, the processing unit 
of the purchaser's financial institution 3 performs a can- 
cellation process. After the completion of the cancella- 
tion process by the processing unit of the purchaser's 
financial institution 3, the termination of cancellation is 
set in the return-of-goods management information 
1 370 and the payment management information 1 340 
in the transaction management DB 55 in step 2518. In 
step 2520, the transaction status 1 320 is also set as 'C- 
6 (payment cancellation)'. 

The return-of-goods confirmation 1379 and the re- 
turn-of-goods claim 1 380 are set in the returned goods 
confirmation/claim acceptance process 2340. When a 
seller receives returned goods, which are physical 
goods, from a deliverer, or when the seller receives a 
cancellation request notification for digital contents from 
the transaction management device 5, the seller has to 
notify the transaction management device 5 of a claim 
against the cancellation or the returnof-goods through 



the confirmation of returned goods within a predeter- 
mined period. 

As shown in FIG. 43, after receipt of a return-of- 
goods confirmation or a return-of-goods claim in step 
5 2342, cancellation is established, if a return-of-goods 
confirmation is received, by transmitting a final settle- 
ment stop instruction and a provisional settlement can- 
cellation request to the purchaser's financial institution 
in and after step 2350. If a return-of-goods claim is re- 
ceived, it is confirmed that the process is in the site mon- 
itor term, and then the return-of-goods claim 1 380 of the 
return-of-goods management information 1370 in the 
transaction management DB 55 is set, and the transac- 
tion status 1320 is set as 'C-5 (return-of-goods claim)', 
thereby suspending the prescription. 

In the above described processes, the transaction 
management device 5 monitors whether or not the seller 
issues a cancellation request through return-of-goods. 
If the cancellation request is not issued within a prede- 
termined period, the third-party return -of -goods certifi- 
cation information is added to the cancellation request, 
and the cancellation request is issued by the transaction 
management device 5 as a substitute. 

Then, the digital contents key (decryption key for 
digital contents) acceptance process 2000, and the dig- 
ital contents receipt confirmation/cancellation process 
2100 are mainly described below as functions of man- 
aging the decryption key for the digital contents to be 
encrypted by a seller and transmitted to a purchaser, 
transmitting the decryption key to the purchaser, issuing 
certification information of a third-party witness, etc. in 
mediating the sales of digital contents. 

When a seller transmits encrypted digital contents 
to a purchaser, the seller simultaneously transmits a de- 
cryption key for use in decrypting the digital contents to 
the transaction management device 5. The digital con- 
tents key acceptance process 2000 receives and proc- 
esses the decryption key (step 2002) as shown in FIG. 
36. In step 2004, the decryption key is stored in the de- 
cryption key 1 335 for digital contents in the goods order 
information 1 330 in the transaction management DB 55, 
and the transaction management device 5 is set in the 
deliverer information 1361 of the delivery management 
information 1 360. The transaction status 1 320 is set as 
'A-4 (accepting delivery) (step 2006). The stored de- 
cryption key 1 335 is hereinafter managed by the trans- 
action management device 5. 

In the digital contents receipt confirmation/cancel- 
lation process 2100, the contents of a request from a 
purchaser about the transmitted digital contents (en- 
crypted) are received and processed as shown in FIG. 
37 (step 21 02). If the purchaser returns a decryption key 
transmission request, then the purchaser intends to pur- 
chase the digital contents, and the decryption key 1 335 
for digital contents in the goods order information 1330 
of the transaction management DB 55 stored in the dig- 
ital contents key acceptance process 2000 is retrieved 
in step 2110 on condition that the transaction status 
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1320 is 'A-4 (accepting delivery)' (step 2106). The re- 
trieved key is transmitted to the purchaser in step 2112. 
The transaction status 1 320 is set as 'A-5 (receiving de- 
livery)' (step 2108). 

Then, the delivery receipt information s 
1 365/1 366/1 367 (third-party delivery certification by the 
transaction management device 5) of the delivery man- 
agement information 1360 in the transaction manage- 
ment DB 55 and the site monitor term 1 373 of the return- 
of-goods management information 1 370 are set (step 10 
2114). Simultaneously, the final settlement site monitor 
DB 56 is generated (step 2116). The data obtained by 
copying the final settlement site monitor term 1363 of 
the delivery management information 1 360 in the trans- 
action management DB 55 is set as the final settlement is 
site monitor term 1402 of the final settlement site mon- 
itor DB 56. 

In mediating the sales of digital contents in the 
above described process, the transaction management 
device 5 manages the decryption key of the digital con- 20 
tents encrypted by the seller and transmitted to the pur- 
chaser, transmits the decryption key to the purchaser, 
and issues the certification information of the third-party 
witness. 

In mediating the sales of digital contents, the trans- 25 
action management device 5 determines whether or not 
the contents received by the purchaser are acceptable. 
If it determines that the contents are not acceptable, it 
is notified to the purchaser. If it is determined that the 
decryption key is defective, then the decryption key is 30 
re-transmitted to the purchaser. This is explained by re- 
ferring to the digital contents receipt confirmation/can- 
cellation process 21 00. This process is performed when 
contents cannot be decrypted in the determination in 
step 2104 in the digital contents receipt confirmation/ 35 
cancellation process 2100 shown in FIG. 37. 

For example, assume that, in step 2112 shown in 
FIG. 37, a decryption key is transmitted to the purchas- 
er's processing unit 1 , but the purchaser cannot decrypt 
the digital contents. At this time, the purchaser may re- 40 
turn a purchase cancellation request together with the 
un-decrypted digital contents. This corresponds to the 
case in which contents cannot be decrypted (impossible 
decryption of contents). 

First, the condition for accepting the request is that 45 
the transaction status 1320 is 'A-5 (receiving delivery)', 
and the final settlement site monitor term 1402 of the 
final settlement site monitor DB 56 does not expire (de- 
terminations in step 2154 and 2156). In the decryption 
check process in step 21 60, it is determined whether the 50 
contents (encrypted) received by the purchaser or the 
decryption key are defective. 

FIG. 39 shows the flow of the decryption check 
process. In step 2162 shown in FIG. 39, the seller is re- 
quested to transmit the contents which are the same as 5 $ 
the contents (encrypted) transmitted to the purchaser. 
Then, it is confirmed in step 21 68 that the contents trans- 
mitted from the seller match the contents (encrypted) 



transmitted from the purchaser. If they don't match, it is 
determined that the contents transmitted from the seller 
to the purchaser are defective, and that the contents 
newly transmitted from the seller to the transaction man- 
agement device 5 are correct, and the correct contents 
are transmitted to the purchaser. If the above described 
contents match each other in steps 2168 and 2170, the 
contents are decrypted using the decryption key 1 335 
managed by the transaction management device 5. Fur- 
thermore, the seller is requested to transmit the non- 
encrypted digital contents after encrypting them using a 
seller's common key exclusive for transmission to the 
transaction management device (step 2174). In step 
21 80, the newly returned digital contents are decrypted, 
compared with the digital contents decrypted in step 
2172 as in the state before encryption, and it is con- 
firmed that they match each other If they match each 
other, then it is determined that the decryption key used 
by the purchaser is defective, the decryption key 1335 
managed by the transaction management device 5 is 
transmitted again to the purchaser in step 2184, and a 
decryption process is requested again. 

If the above described contents do not match each 
other in step 2180, then it is determined that the digital 
contents (encrypted) first transmitted from the seller to 
the purchaser are defective, and a process of re-trans- 
mitting the contents is performed. In and after step 21 86, 
the delivery reception information 1365/1366/1367 of 
the delivery management information 1 360 in the trans- 
action management DB 55 and the site monitor term 
1373 of the return -of-goods management information 
1 370 are set in the state before transmission of the de- 
cryption key, and the final settlement site monitor DB 56 
is deleted. In step 2192, since it is determined that the 
contents first transmitted from the seller to the purchaser 
are defective, it is informed to the seller that the trans- 
mission should start with the contents and digest for 
continuation of the transaction. 

In the above described process, the transaction 
management device 5 determines whether or not the 
contents received by the purchaser are defective in me- 
diating the sales of digital contents. If it is determined 
that the contents are defective, the purchaser is in- 
formed of it and the process of re-transmitting the de- 
cryption key to the purchaser is performed. 

Furthermore, in mediating the deliverer's process- 
ing unit, the seller's processing unit, and the purchaser's 
or the receiver's processing unit, the functions of accept- 
ing the entry of the third-party delivery certification infor- 
mation of the deliverer's processing unit, accepting the 
entry of the first third-party return-of-goods certification 
information certifying that a returnof -goods request has 
been issued, and accepting the entry of the second 
third-party return-of-goods certification information cer- 
tifying that the seller has received returned goods are 
explained by referring to the goods delivery receipt proc- 
ess 1820, the returned goods delivery acceptance proc- 
ess 2200, and the returned goods delivery receipt proc- 
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ess 2220. 

The third-party delivery certification is entered in the 
goods delivery receipt process 1820. The first third-par- 
ty return -of-goods certification is entered in the returned 
goods delivery acceptance process 2200. The second 5 
third-party return-of- goods certification is entered in the 
returned goods delivery receipt process 2220. 

Since the process of accepting an entry of the third- 
party delivery certification in the goods delivery receipt 
process 1820 has been described by referring to FIG. 10 
33, the detailed description is omitted here. 

Next, the returned goods delivery acceptance proc- 
ess 2200 is described below by referring to FIG. 40. In 
step 2202, a notification that the deliverer received from 
a goods receiver a request to deliver goods to be re- '5 
turned and the goods, is received. Then, after checking 
for consistency of the transaction status 1 320 in step 
2204, the deliverer's receipt certification contained in 
the received notification is stored in the first third-party 
return -of-goods certification 1375 and 1376 in the re- 20 
turn-of-goods management information 1370 in the 
transaction management DB 55 in steps in and after 
step 2208. Then, the return-of -goods site monitor switch 
1404 in the final settlement site monitor DB 56 is set as 
'switched', and the date and time is set. The return-of- 2s 
goods site monitor DB 57 is generated, and the trans- 
action status 1320 is set as 'C-1 (accepting a return-of- 
goods request)'. The subsequent site monitor is per- 
formed in the return -of -goods site monitor process 
2500. The return-of-goods site monitor term 1 422 of the 30 
retum-of -goods site monitor DB 57 is set based on the 
number X of days for adjustment in consideration of the 
delivery term. 

Furthermore, the returned goods delivery receipt 
process 2220 receives a notification that the seller has 35 
received returned goods from the deliverer together with 
the seller's receipt certification in step 2222 as shown in 
FIG. 41. After the consistency check of the transaction 
status 1320, a seller's certificate containing the seller's 
receipt certification is stored in the second third-party 40 
return -of-goods certification 1377 and 1378 in the re- 
turn-of-goods management information 1370 of the 
transaction management DB 55, and the return-of- 
goods site monitor term 1422 of the return-of-goods site 
monitor DB 57 is set again based on the determined 45 
number Y of days for adjustment in and after step 

2228. Afterwards, the return-of-goods site monitor 
process 2500 monitors the cancellation by return-of- 
goods using the site monitor term. 

The provisional settlement cancellation request ac- so 
ceptance process 2300 receives a provisional settle- 
ment cancellation request from the purchaser in step 
2302 as shown in FIG. 42, updates the payment man- 
agement information in the transaction management DB 
55 in step 231 2, and transmits the provisional settlement 55 
cancellation request to the purchaser's financial institu- 
tion in step 2316. 

Thus, in mediating the deliverer's processing unit, 



the seller's processing unit, and the purchaser's or the 
receiver's processing unit, the transaction management 
device 5 accepts the entry of the third-party delivery cer- 
tification information of the deliverer's processing unit, 
accepts the entry of the first third-party return-of-goods 
certification information certifying that a return-of-goods 
request has been issued, and accepts the entry of the 
second third-party return-of-goods certification informa- 
tion certifying that the seller has received returned 
goods. 

Described below is the procedure of the transaction 
management device 5 not described yet above. 

All these procedures should be included as pre- 
ferred embodiments. 

The goods order process 1600 mediates the order 
of goods between the purchaser's processing unit 1 and 
the seller's processing unit 2 in the procedure shown in 
FIG. 29. When the order of goods is placed in the pro- 
cedure in steps 1602 through 1608 in the goods order 
process 1600, the transaction management DB 55 is 
generated using the payment ID normally numbered by 
the seller as a key (step 1612). Afterwards, the proceed- 
ings of a transaction are managed through the key. 

When the purchaser places an order of goods, the 
purchaser requests the processing unit at the purchas- 
er's financial institution 3 to issue provisional settlement 
money in the procedure shown in FIG. 30 in the money 
issue process 1700. If the issue of provisional settle- 
ment money is OK in step 1716, the contents of the pro- 
visional settlement money is written to the payment 
management information 1340 of the transaction man- 
agement DB 55 in step 1718, and the subsequent set- 
tlement proceedings are managed. 

When the process is performed in the procedure as 
shown in FIG. 31 , an intermediate process is performed 
in the money payment process 1740 when the purchas- 
er makes payment (provisional settlement) for the 
goods to the seller using provisional settlement money 
or settlement account money. In this procedure, the pro- 
visional settlement date and time 1 346 is written to the 
payment management information 1 340 of the transac- 
tion management DB 55 in step 1750, and the money 
information containing the provisional settlement infor- 
mation through the provisional settlement money or the 
settlement account money is transferred to the seller 
through the transaction management device 5 in step 
1756. 

The notification that the deliverer has accepted the 
delivery of goods from the seller is received from the 
deliverer's processing units 6 and 7 and is entered in 
the goods delivery acceptance process 1800 in a trans- 
action of physical goods in the procedure shown in FIG. 
32. As shown in FIG. 32, when a delivery acceptance 
notification is received from the deliverer in the goods 
delivery acceptance process 1800 : the delivery man- 
agement information 1360 of the transaction manage- 
ment DB 55 is generated (step 1808). 

Described below are the terminal units 80 and 81 
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at the financial institution connected to the processing 
unit at the financial institution 3 and 4, and the portable 
storage media 82 and 83 issued and accepted by the 
above described terminal units as provisional settle- 
ment money cards or final settlement admission request $ 
cards. 

According to the eighth embodiment of the present 
invention, the terminal unit 80 at the financial institution 
operated by a purchaser and the terminal unit 81 at the 
financial institution operated by a seller are referred to. 10 
In the following explanation, a terminal unit having the 
functions operated by both the seller and the purchaser 
are described as the terminal unit 80' at the financial in- 
stitution. 

The terminal unit 80' at the financial institution is op- 1$ 
erated by a purchaser and a seller, transmits and re- 
ceives transaction information to and from the process- 
ing unit at the purchaser's financial institution 3 and 4, 
and have the following functions. 

First, the terminal unit 80* has the function of issuing 20 
the provisional settlement money card 82 for use in a 
purchaser's issuing a provisional settlement request. 

Second, it has the function of allowing the purchas- 
er to perform a final settlement admission process 
based on provisional settlement. 25 

Third, it has the function of processing a final set- 
tlement request from the seller who uses a received 
portable storage medium. 

The terminal unit 80' at the financial institution is de- 
signed as shown in Fl G. 46, and comprises an operation 30 
control unit 3010 for controlling the entire system; a 
communications control unit 3020 line-connected to the 
processing units at the purchaser's financial institution 
3 and 4 to and from which data is transmitted and re- 
ceived; a storage disk 3030 for storing input information 35 
and transmission and receipt information to and from the 
financial institution; an IC card reader/writer 3001 ; a dis- 
play (touch panel) 3002 for inputting information from a 
purchaser and a seller, and displaying receipt informa- 
tion from the processing units at the financial institution 40 
3 and 4; a collected card storage box 3003 for collecting 
used cards; and a new card storage box 3004 for storing 
new cards. The storage disk 3030 can be an arbitrary 
DASD (direct access storage device). 

The operation control unit 3010 comprises a file 
control unit 3011, an input/output control unit 3012, a 
memory file 301 3; and a process unit 301 4. The process 
unit 3014 comprises a portable storage medium issue 
process 3510, a final settlement admission process 
3550, and a final settlement request process 3600. so 

The provisional settlement money card 82 (portable 
storage medium) is, for example, designed to have an 
ICchip 3101 on a plastic card material as shown in FIG. 
47. The memory layout 3110 of the IC chip 3101 is de- 
signed as shown in FIG. 47, and corresponds to a pro- ss 
visional settlement money issue request from a pur- 
chaser, a final settlement admission request from a sell- 
er, or a collection process. Practically, it comprises a 



payment ID 3111, issue information, final settlement re- 
quest information, collection information, provisional 
settlement money information or electronic money infor- 
mation 3122. Among the information, the issue informa- 
tion comprises an issue date and time 3112, issuing fi- 
nancial institution information 3113, issuing financial in- 
stitution branch office information 3114, and issuing ter- 
minal unit information 31 1 5. The final settlement request 
information comprises a final settlement request date 
and time 3116 based on a final settlement request from 
the seller, and final settlement request terminal unit in- 
formation 3117. If the final settlement request informa- 
tion is written, the provisional settlement money card 82 
is prohibited from being reused until it is collected. Then, 
the collection information comprises a collection date 
and time 3118, a collecting financial institution informa- 
tion 311 9 ; a collecting financial institution branch office 
information 3120 : and a collecting terminal unit informa- 
tion 3121. 

Each of the processes performed by the terminal 
unit 80' at the financial institution is described by refer- 
ring to the process flow shown in and after FIG. 48. 

First, the portable storage medium issue process 
35 1 0 is described as a portable storage medium issu ing 
function. 

The portable storage medium issue process 3510 
issues a provisional settlement money card (IC card) as 
a portable storage medium storing money information 
containing provisional settlement information with 
goods purchase information through an operation of a 
terminal unit at financial institution by a purchaser as 
shown in FIG. 48. 

In step 3512, a provisional settlement money (IC 
card type) issue request screen is displayed on the dis- 
play 3002 to accept issue request information such as 
a payment ID, purchaser information, issuing financial 
institution, etc. (step 3514). Then, the contents of the 
issue request information input in step 3516 is con- 
firmed. If the contents are normal in step 3518, and if a 
new IC card exists in the new card storage box 3004 in 
step 3520, then issue request information is transmitted 
to the processing unit of the purchaser's financial insti- 
tution 3 in step 3522. 

Then, it is confirmed in step 3524 that the informa- 
tion has been successfully transmitted. A process result 
is received from the processing unit of the purchaser's 
financial institution 3 in step 

3528. If the process result from the processing unit 
of the purchaser's financial institution 3 is normal in step 
3530, the provisional settlement money information 
containing the goods purchase information is written to- 
gether with issue information to the storage disk 3030. 
A new IC card is extracted from the new card storage 
box 3004 in step 3534, and the provisional settlement 
money information and issue information written to the 
storage disk 3030 are written to the provisional settle- 
ment money information 31 22 and the issue information 
(issue date and time 3112, issuing financial institution 
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information 3113, issuing financial institution branch of- 
fice information 3114, and issuing terminal unit informa- 
tion 31 1 5) of the IC chip memory 31 1 0 of the new IC card 
using the IC card reader/writer 3001. 

If it is confirmed that a write to the IC chip has been 
normally performed in step 3538, then a process termi- 
nation indication is displayed on the display 3002 in step 
3540, and the card 82 is output in step 3542. If input 
contents are not correct in step 3518, if new cards are 
running short in step 3520 : if the transmission process 
is not normally -performed in step 3524, if the process 
result is not correct in step 3530 : or if a write to the IC 
chip is not normally performed in step 3538, then an er- 
ror message is edited in step 3544, and the message is 
displayed on the display 3002 in step 3546. 

The final settlement admission process 3550 is de- 
scribed below as a function of transmitting a final settle- 
ment admission request to financial institution based on 
a portable storage medium. 

The final settlement admission process 3550 is per- 
formed as shown in FIG. 49 to accept a final settlement 
admission request by the purchaser's operating the ter- 
minal unit 80' at financial institution. 

In FIG. 49, the final settlement admission accept- 
ance screen is displayed on the display 3002 in step 
3552 to accept final settlement admission information 
such as a purchaser-input payment ID, purchaser infor- 
mation, issuing financial institution information, etc. If 
the contents of the final settlement admission informa- 
tion input in step 3554 are confirmed and the contents 
are correct in step 3558, then the final settlement ad- 
mission information is transmitted to the processing unit 
of the purchaser's financial institution 3 in step 3560. 

It is confirmed in step 3562 that the information has 
been successfully transmitted. A process result is re- 
ceived from the processing unit of the purchaser's finan- 
cial institution 3 in step 3566. If the process result from 
the processing unit of the purchaser's financial institu- 
tion 3 is normal in step 3568, the process termination 
screen (final settlement admission acceptance indica- 
tion) is displayed on the display 3002 in step 3570. If the 
input contents are not correct in step 3558, if the trans- 
mission process is not normally performed in step 3562, 
and if the process result is not correct in step 3568, then 
an error message is edited in step 3572, and the mes- 
sage is displayed on the display 3002 in step 3574. 

Described below is the final settlement request 
process 3600 as a function of automatically collecting 
portable storage medium. 

The final settlement request process 3600 is a proc- 
ess of accepting a final settlement request through a 
seller's operation of terminal units of financial institution 
and the provisional settlement money card 82 (IC card) 
received from the purchaser as shown in FIG. 50 and 51 . 

First, in step 3602, a final settlement request screen 
is displayed on the display 3002. In step 3604, the pro- 
visional settlement money card 82 inserted by the seller 
is accepted. In step 3606, information stored on the IC 



chip is read using the IC card reader/writer 3001. 

If the information is correctly read in step 3608, then 
a payment ID, issue information, final settlement re- 
quest information, and provisional settlement money in- 
5 formation are written to the storage disk 3030 of the ter- 
minal unit 80' in step 3610. Then, in step 3612, the pay- 
ment ID, issue information, final settlement request in- 
formation, and provisional settlement money informa- 
tion are transmitted to the processing unit of the pur- 

10 chaser's financial institution 3 or the processing unit of 
the seller's financial institution 4. If it is confirmed that 
the transmission is normally performed in step 3614, 
then a process result is received from the processing 
unit of the information receiver's financial institution 3 or 

15 4 in step 3618. 

If the process result of the processing unit of the 
financial institution 3 or 4 is normal in step 3620, it is 
determined whether or not the corresponding provision- 
al settlement money has accepted the final settlement 

20 admission in step 3622. If it is accepted, then the final 
settlement admission information is written to the stor- 
age disk 3030 in step 3624, and then written to the IC 
chip memory 3110 of the provisional settlement money 
card 82 using the IC card reader/writer 3001. After the 

25 final settlement request information and collection infor- 
mation are written to the storage disk 3030 in step 3626, 
they are written to the final settlement request informa- 
tion (final settlement request date and time 3116, final 
settlement request terminal unit information 3117) and 

30 the collection information (collection date and time 31 1 8, 
collecting financial institution information 3119, collect- 
ing financial institution branch office information 3120, 
collecting terminal unit information 3121) in the IC chip 
memory 3110 using the IC card reader/writer 3001. If it 

35 js confirmed that a write to the IC chip has been normally 
performed in step 3628, then the received IC card is col- 
lected in the collected card storage box 3003 in step 
3630, and the final settlement termination indication is 
displayed on the display 3002 in step 3632. 

40 If the corresponding provisional settlement money 
has not accepted the final settlement admission in step 
3622, then the final settlement request information is 
written to the storage disk 3030 in step 3636, and then 
it is written to the final settlement request information 

45 (final settlement request date and time 3116, final set- 
tlement request terminal unit information 31 1 7) in the IC 
chip memory 31 1 0 of the IC card using the IC card read- 
er/writer 3001 . If it is confirmed in step 3638 that a write 
to the IC chip has been normally performed, then a final 

50 settlement request acceptance message is displayed 
on the display 3002 in step 3640. 

If a read from the IC chip is not normally performed 
in step 3608, if the transmission process is not normally 
performed in step 3614, if the process result is not cor- 

55 rect in step 3620, and if a write to the IC chip is not nor- 
mally performed in steps 3628 and 3638, then an error 
message is edited in step 3642, the message is dis- 
played on the display 3002 in step 3644, and a provi- 
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sional settlement money card is output in step 3646. 

The deliverer's processing units (delivery manage- 
ment device) 6 and 7 are described below by referring 
to FIG. 52 and the subsequent figures. The above de- 
scribed fourth embodiment of the present invention in- s 
eludes the deliverer's processing unit 6 for delivering 
normal goods and the deliverer's processing unit 7 for 
delivering returned goods. Since these units can be de- 
signed to have the same configuration, the device hav- 
ing the function of both units is hereinafter referred to 
as a deliverer's processing unit 6*. The delivery manage- 
ment DB 60' of the deliverer's processing unit 6' has the 
functions of the delivery management DB 60 and the 
delivery management DB 70 to manage the normal de- 
livery and the return of goods. 

The deliverer's processing unit 6' has the following 
functions. 

First, based on a goods delivery request from a sell- 
er (seller's processing unit 2), the deliverer's processing 
unit 6' stores goods delivery information. When goods 
are delivered to a receiver, the deliverer's processing 
unit 6' generates the third-parly delivery certification in- 
formation containing the receipt signature of a receiver 
or the substitute signature and a payment ID related to 
the goods purchase. 

Second, based on the receiver's returned goods de- 
livery request, the returned goods delivery information 
is stored and the first third-party return-of-goods certifi- 
cation information containing the receipt signature of the 
receiver who requests the return of goods or the signa- 
ture of a substitute and a payment ID related to the 
goods purchase is generated. 

Third, when returned goods are delivered to the 
seller, the second third-party ret urn -of -goods certifica- 
tion information containing the receipt signature of the 
seller and a payment ID related to the goods purchase 
is generated. 

Fourth, returned goods delivery acceptance receipt 
certification containing a payment ID related to the 
goods purchase is issued to the receiver. 

Fifth, the third-party delivery certification informa- 
tion containing the receipt signature of a receiver and a 
payment ID related to the goods purchase is notified af- 
ter delivery of goods to the seller. 

Sixth, when the transaction management device 5 
mediates, the above described third-party delivery cer- 
tification information, the first and second third-party re- 
turn-of-goods certification information are entered in the 
transaction management device 5. 

To attain the above described functions, the deliv- 
erer's processing unit 6* comprises an operation control 
unit 4010 for controlling the entire system; a communi- 
cations control unit 4012 for line-connection to each of 
the units 1 , 2, 3, 4, and 5; a database control unit 4020 
for controlling each database; a delivery management 
process unit 4480; an input/output process unit 4014; 
and memory 4016 as shown in FIG. 52. 

The database control unit 4020 manages the deliv- 



ery management DB 60' containing delivery information 
4200 and returned goods delivery information 4300, a 
delivery requester information management DB 4400, 
and a delivery destination information management DB 
4450. 

A delivery management process unit 4480 compris- 
es a delivery acceptance process 4500, a delivery re- 
ceipt process 4600, a return-of-goods acceptance proc- 
ess 4700, and a returned goods receipt process 4800. 

Next, each database managed by the database 
control unit 4020 is described below by referring to FIGs. 
53A and 53B. 

As shown in FIG. 52, the delivery management DB 
60 comprises the delivery information 4200 and the re- 
turned goods delivery information 4300. The delivery in- 
formation 4200 contains, as shown in FIG. 53A, a deliv- 
ery ID 4210 which is basic information for use in man- 
aging the delivery by a deliverer; delivery details 4211; 
a payment ID 4220 which is a key to the purchase of 
goods through the communications among persons 
such as a seller, a purchaser, etc. involved in the pur- 
chase of goods; delivery requester information 4230 
and authentication of the requester 4231 ; delivery des- 
tination receipt information 4240 and authentication of 
the destination 4241 ; deliverer authentication 4250; a 
site monitor term 4260 for goods receipt confirmation; a 
discrimination as to whether or not a notification that 
goods have been delivered to a receiver has been given 
to a delivery requester upon delivery of the goods to the 
receiver, and a notification date and time 4270; and a 
discrimination as to whether or not an entry has been 
made in the transaction management device 5, and an 
entry date and time 4280. The core information of the 
third-party delivery certification corresponds to the de- 
livery destination receipt information 4240 and authen- 
tication of the destination 4241, and the deliverer au- 
thentication 4250. 

The returned goods delivery information 4300 con- 
tains information 431 0, 431 1 , and 4320 similar to the de- 
livery information 4200; a site monitor term 4330 for a 
return-of-goods claim; a discrimination as to whether or 
not an entry has been made in the transaction manage- 
ment device 5 and an entry date and time 4340 and 
4350; and first and second return-of-goods certification 
information 4360 and 4370 as shown in FIG. 53A. 

The discrimination as to whether or not an entry has 
been made in the transaction management device 5 and 
the date and time information are represented by two 
types of information, that is, the first return-of-goods cer- 
tification entry 4340 and the second return-of-goods cer- 
tification entry 4350. The first return-of-goods certifica- 
tion entry 4340 indicates whether or not the first return- 
of-goods certification information 4360 has been en- 
tered in the transaction management device 5, and the 
second return-of-goods certification entry 4350 indi- 
cates whether or not the second return-of-goods certifi- 
cation information 4370 has been entered in the trans- 
action management device 5. The first return-of-goods 
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certification information 4360 contains a payment ID 
4361, delivery requester information 4362 and authen- 
tication of the requester 4364, and deliverer authentica- 
tion 4366. The second ret urn -of -goods certification in- 
formation 4370 contains a payment ID 4371, delivery 
destination receipt information 4372 and authentication 
of the destination 4374, deliverer authentication 4376, 
and a delivery date and time 4378. 

The authentication 4241 in the delivery information 
4200 and the authentication 4364 in the returned goods 
delivery information 4300 can be authentication of a 
substitute. 

As shown in FIG. 53B, the contents of the delivery 
requester information management DB 4400 are almost 
the same as the contents of the delivery destination in- 
formation management DB 4450, and contain the re- 
quester or destination ID 4410, attribute information 
(name, address, telephone number, etc.) 4412, trans- 
mission/receipt management information (address, ID, 
etc.) 4414, and authentication information (encryption 
key, etc.) 4416. 

Each of the processes of the delivery management 
process unit 4480 is described below by referring to FIG. 
54 and the subsequent figures. 

FIG. 54 shows the process flow of the delivery ac- 
ceptance process 4500. The delivery acceptance proc- 
ess 4500 accepts a delivery request from a seller in step 
451 0, generates delivery information 4200 in steps 4520 
and 4530, and stores it in the delivery management DB 
60'. The stored contents include the payment ID 4220 
received from the seller, the delivery requester (that is, 
a seller) information 4230 and authentication of the re- 
quester 4231 , and the site monitor term 4260 for goods 
receipt confirmation. If the transaction management de- 
vice 5 mediates, it is notified of the information (step 
4550). 

FIG. 55 shows the process flow of the delivery re- 
ceipt process 4600. First, the goods receipt certification 
information is received from the delivery destination in 
step 4610. If the receiver is absent, the authentication 
of a substitute (member of the family, etc.) can be ac- 
cepted if the substitute can show his or her identity. 
Then, in step 4620, third-party delivery certification in- 
formation is generated. The third-party delivery certifi- 
cation information is obtained by adding the deliverer 
authentication 4250 to the delivery destination receipt 
information 4240 and authentication 4241 stored in the 
delivery information 4200 in the delivery management 
DB 60*. In step 4630, the third-party delivery certification 
information is given to the delivery requester. If the 
transaction management device 5 mediates, the trans- 
action management device 5 is notified of this informa- 
tion (step 4650). Then, the delivery destination receipt 
information 4240 and authentication 4241 in the delivery 
information 4200 in the delivery management DB 60', 
the deliverer authentication 4250, the discrimination as 
to whether or not the notification to the delivery request- 
er has been made and the notification date and time 



4270, and the discrimination as to whether or not an en- 
try has been made in the transaction management de- 
vice 5, and the entry date and time 4280 are updated 
(step 4660). 

5 The above described process has the following 
functions. That is, in response to the goods delivery re- 
quest from the seller, goods delivery information is 
stored. When the goods are delivered to a receiver, the 
third-party delivery certification information containing 
10 the receiver's reception signature or a substitute's sig- 
nature, and a payment I D related to the goods purchase 
is generated. The third-party delivery certification infor- 
mation containing the payment ID related to the goods 
purchase is entered in the transaction management de- 
'5 vice. Furthermore, the seller is informed of the third-par- 
ty delivery certification information containing the re- 
ceiver's receipt signature and the payment ID related to 
the goods purchase after the delivery of the goods. 

Then, the return -of -goods acceptance process 
4700 is described by referring to the process flow shown 
in FIG. 56. 

The return-of-goods acceptance process 4700 
starts when a request is received from a goods receiver 
(purchaser or a person specified by the purchaser) or a 
substitute for the goods receiver. However, if the substi- 
tute issues a request, the substitute has to show his or 
her identity. First in the return-of-goods acceptance 
process 4700, a returned goods delivery request is re- 
ceived in step 4710. The returned goods delivery infor- 
mation 4300 is generated in step 4720, and stored in 
the delivery management DB 60' in step 4730. The 
stored contents are the payment ID 4320 received from 
the receiver, the delivery requester information 4362 
and authentication of the requester 4364, and the site 
monitor term 4330 for a return-of-goods claim. Then, in 
step 4740, the first third-party return-of-goods certifica- 
tion information is generated. This information is ob- 
tained by adding the deliverer authentication 4366 to the 
delivery requester information 4362 and authentication 
4364. It is issued to a delivery requester as a receipt 
certification from the deliverer (step 4750). If the trans- 
action management device 5 mediates, the transaction 
management device 5 is notified of this information (step 
4770). Then, in step 4780, the first return-of-goods cer- 
tification information 4360 and the first return-of-goods 
certification entry 4340 in the returned goods delivery 
information 4300 in the delivery management DB60' are 
updated. 

The above described process has the following 
functions. That is, the returned goods delivery informa- 
tion is stored at a returned goods delivery request from 
a goods receiver, and the first third-party return-of- 
goods certification information containing the signature 
of a receiver who issues a return-of-goods request or 
the signature of a substitute, and a payment ID related 
to the purchase of goods is generated. The third-party 
return-of-goods certification information containing the 
payment ID related to the purchase of goods is entered 
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in the transaction management device. Furthermore, re- 
turned goods delivery acceptance receipt certification 
containing the payment ID related to the purchase of 
goods is issued to the receiver. 

Next, the returned goods receipt process 4800 is 
described by referring to the process flow shown in FIG. 
57. 

When a deliverer is requested by a purchaser to de- 
liver returned good, the deliverer delivers goods to be 
returned to the delivery destination, that is, the seller of 
the goods. In the returned-goods receipt process 4800, 
in step 4810, returned goods acceptance certification is 
received from the seller. In response to the certification, 
the second return-of -goods certification information is 
generated in step 4820. This information is obtained by 
adding the deliverer authentication 4376 and the deliv- 
ery date and time 4378 to the delivery destination receipt 
information 4372 in the returned goods delivery infor- 
mation 4300 in the delivery management DB 60' and au- 
thentication 4374. If the transaction management de- 
vice 5 mediates, the transaction management device 5 
is notified of this information (step 4830). Then, in step 
4840, the second third-party return-of -goods certifica- 
tion 4370, the second ret urn -of -goods certification entry 
4350, and the site monitor term 4330 for the return-of- 
goods claim in the returned goods delivery information 
4300 in the delivery management DB 60' are updated. 
The site monitor term 4330 is determined at arrival of 
returned goods. 

The above described process has the following 
functions. That is, when returned goods are delivered to 
a seller, the second third-party return-of -goods certifica- 
tion information containing the receipt signature of the 
seller and a payment ID related to the purchase of goods 
is generated, and the second third-party return -of -goods 
certification information containing the payment ID re- 
lated to the purchase of goods is entered in the trans- 
action management device. 

Next, the processing unit at the purchaser's or the 
seller's financial institution 3 and 4 are described below. 
The processing unit at the financial institution 3' corre- 
sponds to the processing unit at the purchaser's finan- 
cial institution 3 or the processing unit at the seller's fi- 
nancial institution 4. 

The processing unit at the financial institution 3' is 
provided in a financial institution for issuing provisional 
settlement money to a purchaser, admitting final settle- 
ment, canceling provisional settlement, issuing final set- 
tlement request from a seller, making payment based 
on the contents of a request for receipt of transfer, can- 
celing transfer provisional settlement, monitoring provi- 
sional settlement cancellation site according to return- 
of -goods, etc., and has the following functions. 

First, a provisional settlement money issue request 
is accepted from the purchaser and provisional settle- 
ment money is issued. 

Second, a final settlement request is accepted from 
the seller after receipt of the provisional settlement mon- 



ey. 

Third, a final settlement admission request is ac- 
cepted from the purchaser after receipt of the goods. A 
payment process is performed for the seller according 
5 to request information for receipt of transfer included in 
the final settlement request If the final settlement re- 
quest is not accepted from the seller, then the final set- 
tlement request is demanded. 

Fourth, a provisional settlement cancellation re- 
10 quest according to returned goods can be accepted 
from the purchaser. 

Fifth, when the purchaser requests return-of-goods 
to a deliverer, the first third-party retum-of-goods certi- 
fication can be accepted from the deliverer. 
1$ Sixth, when the deliverer transmits returned goods 
to the seller, the second third-party return-of-goods cer- 
tification is accepted from the transaction management 
device 5. 

Seventh, when the returned goods are somewhat 
defective, then a retum-of-goods claim can be accepted 
from a seller. 

Eighth, when goods are successfully returned, a re- 
turned goods receipt notification is accepted from the 
seller. 

Ninth, when the purchaser performs a return-of- 
goods process, the provisional settlement cancellation 
site is monitored. 

To attain the above described functions, the 
processing unit at the financial institution 3' is designed 
as shown in FIG. 58. That is, the processing unit at the 
financial institution 3' comprises an operation control 
unit 5010 for controlling the entire system; a communi- 
cations control unit 5020 for line-connection to each of 
the units 1 , 2, 5, 6 ; and 7 to or from which information 
is transmitted or received; a database control unit 5040 
for controlling each database; a financial process unit 
5700 for performing each of the functions of the process- 
ing unit at the financial institution 3'; an input/output 
process unit 5030; and memory 5050. 

The database control unit 5040 comprises an ac- 
count management DB 51 00, a money management DB 
5200, a provisional settlement money management DB 
5300, an electronic money management DB 5400, a fi- 
nal settlement information management DB 5500, and 
return-of-goods management DB 5600 as shown in FIG. 
58. 

The financial process unit 5700 comprises a provi- 
sional settlement money and electronic money issue 
process 5710, a final settlement request acceptance 
process 5750, a final settlement admission request, ac- 
ceptance process 5800, a provisional settlement can- 
cellation request acceptance process 5850, a first third- 
party return-of-goods certification information accept- 
ance process 5900, a second third-party return-of- 
goods certification information acceptance process 
5920, a retum-of-goods claim notification acceptance 
process 5940, a returned goods receipt notification ac- 
ceptance process 5960, and a provisional settlement 
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cancellation site monitor process 5980. 

FIG. 59 shows the concept of the configuration of 
each database managed by the database control unit 
5040. 

As shown in FIG. 59, the account information of a 
purchaser is managed in the account management DB 
5100. The account information is linked to the money 
management DB 5200 s and the issue state of the pro- 
visional settlement money and the settlement account 
money is managed in the money management DB 5200. 
The provisional settlement money and electronic money 
referred to through the information in DB 5200 are 
stored in the provisional settlement money manage- 
ment DB 5300 and the electronic money management 
DB 5400. The final settlement state of the provisional 
settlement money or electronic money stored in the DBs 
5300 and 5400 is managed and stored in the final set- 
tlement information management DB 5500. The pur- 
chaser's return-of -goods state is managed in the return- 
of-goods management DB 5600. 

Each of the databases is described in detail by re- 
ferring to FIGs. 60A, 60B, 60C, 60D, 60E, and 61. 

As shown in FIG. 60A, the account management 
DB 51 00 is used for management of the purchasers' ex- 
isting account information, and generated using an ac- 
count number 5101 as a key. An account information 
5102 contains personal information 5103 including the 
address, name, and phone number, etc. of a purchaser 
and is used to confirm the purchaser. An account bal- 
ance 5104 represents the balance of the account + bal- 
ance of creditable amount - balance of used credit. 

The money management DB 5200 is generated us- 
ing an account number 5201 as a key as shown in FIG. 
60B, and is linked to the account management DB 51 00. 
Each time a purchaser issues provisional settlement 
money and electronic money (after adding goods pur- 
chase information), a provisional settlement money is- 
sue balance 5203 and electronic money issue balance 
5204 are updated to manage the issuable limit amount. 
Assuming that the account balance 5104 is a, the pro- 
visional settlement money issue balance 5203 is b, and 
the electronic money issue balance 5204 is c, a > b + c 
holds. Provisional settlement money management infor- 
mation 5205 contains the link information to the provi- 
sional settlement money management DB 5300, and 
electronic money management information 5206 con- 
tains the link information to the electronic money man- 
agement DB 5400. 

FIG. 60C shows the provisional settlement money 
management DB 5300. The provisional settlement mon- 
ey management DB 5300 stores the provisional settle- 
ment money issued to a purchaser. That is, as shown 
in FIG. 60C, the provisional settlement money contains 
a provisional settlement money ID 5301 , a payment ID 
5302, an amount 5303, an issue date and time 5304, a 
goods purchase information 5305, financial institution 
identification (authentication) information 5306, payee 
information 5307, a discrimination as to whether or not 



a final settlement request has been issued by a seller 
and its date and time 531 0, a discrimination as to wheth- 
er or not a final settlement admission request has been 
issued by a purchaser and its date and time 5311 , and 
s issuing financial institution blind signature information 
5312. In the provisional settlement money, the goods 
purchase information 5305 contains purchase goods in- 
formation, number X of days for adjustment (X =: aver- 
age number of days for delivery + number of days for 
10 return-of -goods claim acceptance + number of addition- 
al days for allowance), and number Y of days for adjust- 
ment (Y = number of days for return -of -goods claim ac- 
ceptance). The payee information 5307 contains seller 
information 5308 including the address, name, phone 
number, etc. of the seller, and request for receipt of 
transfer information 5309 such as a payee (seller), pay- 
ment method, etc. 

FIG. 60D shows the electronic money management 
DB 5400. The electronic money stored in the electronic 
money management DB 5400 is preliminarily issued to 
a purchaser so that the purchaser can add goods pur- 
chase information to it. After it is paid to the seller, the 
seller issues a final settlement request. Most of the items 
in the electronic money management DB 5400 s that is, 
items 5403, 5404, 5405, 5406, 5407, 5408, 5409, 5410, 
5411, and 5412 are based on the money management 
DB 5200. However, it is different from the money man- 
agement DB 5200 in that the electronic money ID can 
be a source ID 5401 and an additional child ID 5402, 
and contains blind signature information 5413. 

FIG. 60E shows the final settlement information 
management DB 5500. The record stored in the final 
settlement information management DB 5500 is gener- 
ated when a final settlement admission from a purchas- 
er or a final settlement request from a seller is received, 
and the final settlement request for the money informa- 
tion containing the provisional settlement information is 
issued to a financial institution. The generated record is 
used in the subsequent management. The final settle- 
ment information management DB 5500 is generated 
using a payment I D 5501 as a key and contains a money 
type 5502 indicating either the settlement account mon- 
ey or the provisional settlement money; a provisional 
settlement money ID or an electronic money ID 5503; 
and a discrimination as to whether or not a final settle- 
ment has been made and its date and time 5504. 

Next, the return-of-goods management DB 5600 is 
described below by referring to FIG. 61. The return-of- 
goods management DB 5600 is generated when a pro- 
visional settlement cancellation request with the first 
third-party return-of-goods certification is received from 
a purchaser of goods, and the generated database is 
used in the subsequent management. The return-of- 
goods management DB 5600 is generated using a pay- 
ment ID 5601 as a key, and comprises a return-of-goods 
management information 5602 for use in managing the 
information about a deliverer who receives a return-of- 
goods request from the purchaser, a return-of-goods re- 
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quest date and time, etc. ; a money type 5603 (either set- 
tlement account money or provisional settlement mon- 
ey); a provisional settlement money ID or a electronic 
money ID 5604; a provisional settlement cancellation re- 
quest date and time and authentication 5605; a provi- & 
sional settlement cancellation request date and time 
and authentication 5605; a delivery ID 5606; a number 
of days for adjustment 5607 required for site monitor of 
final settlement after delivery of goods to a purchaser 
and provisional settlement cancellation in a return-of- 10 
goods process; a return-of -goods claim information date 
and time and authentication 5608; a returned goods de- 
livery completion notification date and time and authen- 
tication 5609; and a return-of -goods admission notifica- 
tion date and time and authentication 5610. '5 

Next, each of the processes 5710 through 5980 
contained in the banking process unit 5700 are de- 
scribed below by referring to FIGs. 62 through 70. 

FIG. 62 is a flowchart showing the provisional set- 
tlement money and electronic money issue process 20 
5710. First, in the provisional settlement money and 
electronic money issue process 5710, a provisional set- 
tlement money or electronic money issue request is re- 
ceived from the purchaser's processing unit 1 (step 
571 2). Then, based on the protocol of a provisional set- 25 
tlement money and electronic money issue request, the 
format is checked, the number of digits and the item type 
of each item are checked for attribute, whether or not 
the personal identity confirmation information is input is 
checked, and the financial institution identifier is 30 
checked for validity (steps 5714 and 5716). If the check 
result is NG, the purchaser's processing unit 1 is in- 
formed of an error (step 5734). If it is normal, the account 
management DB 5100 is continuously accessed based 
on the account number contained in the request (steps 35 
5718 and 5720). 

If there are no account records as a result of the 
access to the account management DB 5100, then the 
purchaser's processing unit 1 is informed of the error 
(step 5734). If there is an account record, then the con- 40 
firmation information of the contents of the provisional 
settlement money or the electronic money issue request 
is compared with the personal information in the account 
information entered in the record so that the validity of 
the purchaser is checked. 45 

Furthermore, the issue amount of the provisional 
settlement money or electronic money issue request is 
compared with the balance in the record and credit in- 
formation, and it is checked whether the balance + cred- 
itable amount - used credit amount is larger or smaller so 
than the issue amount (steps 5722 and 5724). If an error 
occurs in the check process, the purchaser's processing 
unit 1 is notified of the contents of the error (step 5734). 
If the result of a check is normal, then the issue amount 
is subtracted from the balance of the account record, 55 
the balance (including the amount of used credit 
amount) is updated, and the corresponding account 
record in the account management DB 5100 is overwrit- 



ten. 

Furthermore, the money management DB 5200 is 
accessed using the account number. If the issued mon- 
ey type is the provisional settlement money, then the is- 
sue amount is added to the provisional settlement mon- 
ey issue balance, the number of issued pieces as the 
provisional settlement money management information 
is updated, and the provisional settlement money IDs 
for the number of issue requests are newly numbered 
and stored additionally. If the money type is the settle- 
ment account money, then the issue amount is added 
to the electronic money issue balance, the number of 
issued pieces is updated as electronic money manage- 
ment information, and the electronic money IDs for the 
number of issue requests are newly numbered and 
stored additionally. If there is no money management 
DB 5200, then the DB is generated (STORE). If the mon- 
ey management DB 5200 exists, it is rewritten (step 
5726). 

If the type of issued money is provisional settlement 
money, then the provisional settlement money manage- 
ment DB 5300 is generated by storing a provisional set- 
tlement money ID, an issue amount, an issue date and 
time, issuing financial institution identification (authenti- 
cation) information, etc. in a record for each of the newty 
numbered provisional settlement money IDs. If the pro- 
visional settlement money requires the use manage- 
ment, then goods purchase information and payee in- 
formation are added to the record and stored therein. A 
blind signature is generated for important items in the 
goods purchase information and payee information and 
stored therein (step 5728). If the type of money is set- 
tlement account money, a record containing necessary 
information is generated similarly. 

Then, the generated contents are stored as the pro- 
visional settlement money management DB 5300 or the 
electronic money management DB 5400 (step 5730). 

Finally, the provisional settlement money or elec- 
tronic money is generated based on the record gener- 
ated in the money management DB 5200 and the pro- 
visional settlement money management DB 5300 or the 
electronic money management DB 5400, and is then 
transmitted to the purchaser's processing unit 1 (step 
5732). 

FIG. 63 is a flowchart showing the process of the 
final settlement request acceptance process 5750. First, 
in step 5752, the final settlement request acceptance 
process 5750 accepts a final settlement request from 
the seller's processing unit 2. 

Next, in the processes in steps 5754 through 5778, 
the contents of a final settlement request is checked for 
validity, and the request for receipt of transfer informa- 
tion contained in the final settlement request is set in the 
provisional settlement money management DB 5300 or 
the electronic money management DB 5400. If no pay- 
ment ID is set, the payment ID in the final settlement 
request is set and the DB is updated. 

If a final settlement admission request has been ac- 
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cepted already, the correlation check is made in the final 
settlement information management DB 5500. If the 
check result is normal, the final settlement information 
management DB 5500 is updated and a payment proc- 
ess is performed based on the contents of the request 
for receipt of transfer in the provisional settlement mon- 
ey management DB 5300 or the electronic money man- 
agement DB 5400. If a final settlement admission re- 
quest has not been issued, the final settlement informa- 
tion is set as 'not made' and the final settlement infor- 
mation management DB 5500 is generated. 

FIG. 64 is a flowchart showing the final settlement 
admission request acceptance process 5800. The final 
settlement admission request acceptance process 5800 
accepts a final settlement admissiqn request from the 
purchaser's processing unit 1 and the transaction man- 
agement device 5 in step 5802. 

Next, in the processes in steps 5804 through 5832, 
the accepted final settlement admission request is 
checked for validity, and the final settlement admission 
requester is checked for authorization. If the check re- 
sults are normal, the final settlement admission request 
information is set in the provisional settlement money 
management DB 5300 or the electronic money manage- 
ment DB 5400. If the payment ID of the DB is not set, 
then the payment ID in the final settlement admission 
request is set and the DB is updated. 

If a final settlement request has been received, the 
correlation check is made in a final settlement informa- 
tion management DB. If the check result is normal, a 
payment process is performed based on the contents of 
the request for receipt of transfer in the provisional set- 
tlement money management DB 5300 or the electronic 
money management DB 5400. If a final settlement re- 
quest has not been issued, the final settlement informa- 
tion is set as 'not made' and the final settlement infor- 
mation management DB 5500 is generated. Further- 
more, a demand notification for the final settlement re- 
quest is issued to the seller's processing unit 2 or the 
transaction management device 5. 

FIG. 65 is a flowchart showing the provisional set- 
tlement cancellation request acceptance process 5850. 
The provisional settlement cancellation request accept- 
ance process 5850 accepts a provisional settlement 
cancellation request from the seller's processing unit 2 
or the transaction management device 5 in step 5852. 
Then, in the processes in steps 5854 through 5872, the 
validity of the contents of the accepted provisional set- 
tlement cancellation and the authorization of the provi- 
sional settlement cancellation requester are checked. If 
the check results are normal, a flag indicating that pro- 
visional settlement cancellation has occurred is set in 
the provisional settlement money management DB 
5300 or the electronic money management DB 5400, 
and the provisional settlement money management DB 
5300 or the electronic money management DB 5400 are 
updated. 

Furthermore, provisional settlement cancellation 



request information (acceptance date and time, re- 
quester information, etc.) in the return-of-goods man- 
agement DB 5600 is set to generate the return-of-goods 
management DB 5600. A provisional settlement cancel- 

5 lation acceptance notification is issued to a provisional 
settlement cancellation requester. 

FIG. 66 is a flowchart showing the first third-party 
return-of-goods certification information acceptance 
process 5900. First, in step 5902, the first third-party re- 

io turn-of-goods certification information acceptance proc- 
ess 5900 accepts the first third-party return-of-goods 
certification information from the purchaser's process- 
ing unit 1 or the transaction management device 5. 
Then, in the processes in steps 5904 through 591 4, 

'5 the validity of the accepted first third-party return-of- 
goods certification information, and the authorization of 
the requester of the first third-party return-of-goods cer- 
tification information requester are checked. If the check 
results are normal, then the number X of days for ad- 

20 justment is obtained to monitor the number of days for 
adjustment. The number X of days for adjustment is 
computed by the equation X = number of days for deliv- 
ery in goods purchase information + number of days for 
acceptance of retum-of -goods claim in goods purchase 

25 information + predetermined number of additional days 
for allowance - (first third-party return-of-goods certifi- 
cation information acceptance date - return-of-goods re- 
quest acceptance date in first third-party return-of- 
goods certification information). The obtained number 

30 x of days for adjustment is set in the return-of-goods 
management DB 5600, and the return-of-goods man- 
agement DB 5600 is updated. 

FIG. 67 is a flowchart showing the second third-par- 
ty return-of-goods certification information acceptance 

35 process 5920. In step 5922, the second third-party re- 
turn-of-goods certification information acceptance proc- 
ess 5920 accepts the second third-party return-of- 
goods certification information from the transaction 
management device 5. Then, in the processes in steps 

40 5924 through 5934, the validity of the contents of the 
second third-party return-of-goods certification informa- 
tion, and the authorization are checked. If the-check re- 
sults are normal, the number Y of days for adjustment 
is obtained to monitor the number of days for adjust- 

45 ment. The number Y of days for adjustment is computed 
by the equation Y = number of days for acceptance of 
return-of-goods in goods purchase information - (sec- 
ond third-party retum-of -goods certification information 
acceptance date - seller receipt date in second third- 

50 party return-of-goods certification information). The ob- 
tained number Y of days for adjustment is set in the re- 
turn-of-goods management DB 5600, and the return-of- 
goods management DB 5600 is updated. 

FIG. 68 is a flowchart showing the return-of-goods 

55 claim notification acceptance process 5940. First, in 
step 5942, the return-of-goods claim notification accept- 
ance process 5940 accepts a return-of-goods claim 
from the seller's processing unit 2 or the transaction 
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management device 5. Then, the processes in steps 
5044 through 5958 are performed, and the validity of the 
contents of the accepted return -of -goods claim notifica- 
tion and the authorization of the ret urn -of -goods claim 
notification requester are checked. If the check results s 
are normal, then the return-of-goods claim acceptance 
date and time and the return-of-goods claim notification 
requester information are set in the return-of-goods 
claim information 5608 of the retum-of-goods manage- 
ment DB 5600, and the return-of-goods management 
DB5600 is updated. The return-of-goods claim notifica- 
tion requester is notified that a return-of-goods claim no- 
tification has been accepted, and the purchaser's 
processing unit 1 is notified that a return-of-goods claim 
has been issued. 

FIG. 69 is a flowchart showing the returned goods 
receipt notification acceptance process 5960. The re- 
turned goods receipt notification acceptance process 
5960 accepts a return-of-goods receipt notification from 
the seller's processing unit 2 or the transaction manage- 
ment device 5 (step 5962). Then, the processes in steps 
5964 through 5980 are performed, and the validity of the 
contents of the accepted return-of-goods receipt notifi- 
cation and the authorization are checked. If the check 
results are normal, the returned goods receipt notifica- 
tion acceptance date and time, and the requester infor- 
mation of the returned goods receipt notification are set 
in the return-of-goods admission notification 5610 in the 
retum-of-goods management DB 5600, the number of 
days for adjustment 5607 are cleared to 0, and the re- 
turn-of-goods management DB 5600 is updated. Fur- 
thermore, if return-of-goods claim information is set, 
then an invalid flag for return-of-goods claim information 
is set. 

If the final settlement information management DB 
5500 exists, it is deleted and the amount of the provi- 
sional settlement money management DB 5300 or the 
electronic money management DB 5400 is subtracted 
from the balance of the provisional settlement money 
issue balance or the balance of the electronic money 
issue balance in the money management DB 5200, and 
the money management DB 5200 is updated. 

The amount to be canceled is added to the account 
balance in the account management DB 5100, and the 
account management DB 5100 is updated. The provi- 
sional settlement money management DB 5300 or the 
electronic money management DB 5400 which has be- 
come unnecessary through the cancellation is deleted 
after a predetermined allowance period in order to avoid 
possible trouble. A cancellation completion notification 
is transmitted to a returned goods receipt notification re- 
quester and the purchaser's processing unit 1 . 

FIG. 70 is a flowchart showing the provisional set- 
tlement cancellation site mon itor process 5980. The pro- 
visional settlement cancellation site monitor process 
5980 performs the processes in steps 5982 through 
5998 once a day, and checks the contents of the return- 
of-goods management DB 5600. If the information 



about the return-of-goods admission notification 5610 
exists in the return-of-goods management DB 5600, the 
process similar to the provisional settlement cancella- 
tion process shown in FIG. 69 is performed. 

If the return-of-goods claim information 5608 exists, 
the process terminates without changing the number of 
days for adjustment 5607. If neither the return-of-goods 
admission notification 5610 nor the return-of-goods 
claim information 5608 exists, then it is checked whether 
or not the information of the provisional settlement can- 
cellation request 5605 exists. If the provisional settle- 
ment cancellation request 5605 exists, the number of 
days for adjustment 5607 is checked. If the number of 
days for adjustment is zero, the process similar to the 
provisional settlement cancellation process in FIG. 69 
is performed. If the number of days for adjustment is not 
zero, then 1 is subtracted from the number, and the re- 
turn-of-goods management DB 5600 is updated. 

Next, the practical configuration of the purchaser's 
processing unit 1 is described by referring to FIG. 71 
and subsequent figures. 

The purchaser's processing unit 1 is provided for a 
purchaser to perform operations from order to settle- 
ment in purchasing goods, and to issue a return-of- 
goods request. The purchaser's processing unit 1 has 
the following functions. 

First, an issue request for money information con- 
taining provisional settlement information which is finally 
settled based on the confirmation of the contents of the 
goods received from a seller after transferring to the sell- 
er is made. 

Second, an entry request for goods purchase infor- 
mation is issued for the money information containing 
the provisional settlement information. 

Third, a goods order request is issued to a seller, 
money information containing provisional settlement in- 
formation is transferred to a seller, and purchaser's per- 
sonal identity confirmation information is transmitted. 

Fourth, based on the confirmation of the contents 
of the received goods, a final settlement admission re- 
quest is issued when the goods are normal, a return-of- 
goods request is issued when goods are not normal, a 
first third-party return-of-goods certification information 
certifying that a return-of-goods request has been re- 
ceived is accepted, and a provisional settlement cancel- 
lation request is issued. 

To attain this, the purchaser's processing unit 1 is 
designed as shown in FIG. 71 . In FIG. 71 , the purchas- 
er's processing unit 1 comprises an operation control 
unit 6010 for controlling the entire system; a communi- 
cations control unit 6020 for line-connection to each of 
the seller's processing unit 2, the processing unit of the 
purchaser's financial institution 3, the transaction man- 
agement device 5, the deliverer's processing units 6 and 
7; a database control unit 6040 for controlling each da- 
tabase; a payment process unit 6600 for performing 
each process of the purchaser's processing unit 1 ; an 
input device 6030; and a memory 6050. 
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As shown in FIG. 71 , the database control unit 6040 
manages a goods purchase management DB 6100, a 
money management DB 6200, a provisional settlement 
money management DB 6300, an electronic money 
management DB 6400; a final settlement admission re- 
quest management DB 6500; and a return-of-goods re- 
quest management DB 6600. 

The payment process unit 6800 includes and per- 
forms the money information issue request process 
6610, the goods order process 6650, and the goods re- 
ceipt and return-of-goods process 6700 as shown in 
FIG. 71. 

Each of the databases managed by the database 
control unit 6040 is described below by referring to FIGs. 
72A ; 72B, 72C, 72D, and 73. 

The configuration of the goods purchase manage- 
ment DB 61 00 is shown in FIG. 72A. A payment ID 6101 
is a key ID for management of money information, final 
settlement, and return of goods. Goods purchase infor- 
mation 6102 is goods purchase detailed information 
containing the information about a seller. An order date 
and time 6103 indicates the date and time of a goods 
purchase order. A payment method 6104 is a payment 
method (for example, prepayment, provisional settle- 
ment, payment after receipt of goods, etc.) specified 
when a purchaser places an order. A money type 6105 
indicates the type of money (settlement account money/ 
provisional settlement money, etc.) for the payment. A 
money ID 6106 is an ID of paid electronic money or pro- 
visional settlement money. A provisional payment date 
and time 61 07 is a date and time of the provisional set- 
tlement. A final settlement admission date and time 
6108 is a date and time of the purchaser's final settle- 
ment admission. A seller information 6109 includes the 
name, address, office, bank information, electronic 
money payment destination, etc. and contains authen- 
tication 6110. The authentication 6110 is an authentica- 
tion of the seller for the seller information 6109. 

The money management DB 6200 stores, as shown 
in FIG. 72B, account information 6201 containing the in- 
formation about a settlement account (financial institu- 
tion, account number); a provisional settlement money 
issue balance 6203; an electronic money issue balance 
6204; provisional settlement money management infor- 
mation 6205; and electronic money management infor- 
mation 6206. The provisional settlement money man- 
agement information 6205 is pointer information (link in- 
formation) to the provisional settlement money manage- 
ment DB 6300, and the electronic money management 
6206 is pointer information to the electronic money man- 
agement DB6400. 

The contents of the provisional settlement money 
management DB 6300 include a provisional settlement 
money ID 6301, a payment ID 6302, an amount 6303, 
an issue date and time 6304, goods purchase informa- 
tion 6305 linked to money, issuing financial institution 
information 6306, and a final settlement or provisional 
settlement cancellation completion date and time 6307. 



Among them, the provisional settlement money ID 6301 
is a money ID numbered by a financial institution when 
it is issued, and relates to a payment ID. The final set- 
tlement or provisional settlement cancellation comple- 
5 tion date and time 6307 indicates the date and time 
when the life cycle of the provisional settlement money 
has been terminated through the completion of the final 
settlement or provisional settlement cancellation. 

The configuration of the final settlement admission 
request management DB 6500 is shown in FIG. 72C. In 
FIG. 72C : a payment ID 6501 , a money type 6502, and 
a money ID 6503 correspond to the same items in the 
goods purchase management DB 6100. The final set- 
tlement admission request date and time 6504 corre- 
sponds to the final settlement admission date and time 
6108 of the goods purchase management DB 6100. A 
final settlement completion notification date and time 
6505 is a date and time on which the completion of the 
final settlement has been received from the financial in- 
stitution after a final settlement admission request is is- 
sued. 

The return-of-goods request management DB 6600 
is generated when return of goods arises. The configu- 
ration is shown in FIG. 72D. The contents of the DB 6600 
include items 6601, 6602, and 6603 based on the final 
settlement admission request management DB 6500, 
and a date and time 6604, a deliverer 6605, and a first 
third-party return-of-goods certification 6606 as receipt 
information (return-of-goods request information) when 
a return-of-goods request is issued to the third-party wit- 
ness such as the deliverer's processing unit. It further 
includes a discrimination as to whether or not a provi- 
sional settlement cancellation request has been issued 
and its date and time 6607 when a provisional settle- 
ment cancellation request through return-of-goods is 
notified for financial institution; and a discrimination as 
to whether or not the provisional settlement cancellation 
has been completed and its date and time 6608. 

The electronic money management DB 6400 man- 
ages the information shown in FIG. 73. The electronic 
money managed in the electronic money management 
DB 6400 is, unlike the provisional settlement money, is- 
sued by a financial institution without first specifying its 
use. That is, this electronic money is referred to as set- 
tlement account money. In FIG. 73, the upper portion 
corresponds to the management information of the elec- 
tronic money (settlement account money) issued by a 
financial institution, and the lower portion corresponds 
to the electronic money information containing the pro- 
visional settlement information indicating that the pur- 
chaser has paid to the seller a part of the electronic mon- 
ey to purchase specific goods. 

The management information shown in the upper 
portion contains an electronic money ID 6401 of issued 
money, an issue amount 6402 for the time being, a valid 
term 6403, a final settlement type (final payment type) 
drawing information 6404 and its accumulated amount 
6405, a provisional settlement type (provisional pay- 
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ment type) drawing information 6406 and its accumulat- 
ed amount 6407, and an issue balance 6408. 

The money information containing the provisional 
settlement information in the lower portion indicates a 
part of the issue amount 6402 drawn as a provisional 5 
settlement type. Therefore, the money ID is specified by 
adding a child ID 6410 to a source ID 6409 (same as 
the ID 6401 in the upper portion). Other items 6411, 
641 2, 641 3, 641 4, 641 5, and 641 6 are all based on the 
provisional settlement money management DB 6300. 10 
However, the settlement account money is provided 
with a blind signature by a purchaser when it is drawn, 
and is different from the provisional settlement money 
to be provided with a blind signature by a financial insti- 
tution. 15 

The process procedure of each process in the pur- 
chaser's processing unit 1 is described below by refer- 
ring to FIG. 74 and subsequent figures. 

By referring to FIG. 74, the procedure of a money 
information issue request process 6610 is described as 20 
a function of issuing provisional settlement money. 

As shown in FIG. 74, information about a financial 
institution to which an issue of provisional settlement 
money is requested, and information relating to the is- 
sue request such as an amount, etc. are input in step 25 
6612 in the money information issue request process 
6610. The amount (bl) is determined within a range of 
the account balance 5104 of the account management 
DB 5100 shown in FIG. 61 A. Then, in step 6614, infor- 
mation such as an account number is input. It is deter- 30 
mined in step 661 6 whether or not it is necessary to add 
goods purchase information. If yes, the goods purchase 
information is added in step 6618. In step 661 9, the gen- 
erated issue request is transmitted to the processing 
unit of the purchaser's financial institution 3. 35 

Then, in step 6622, a process result is received from 
the processing unit of the purchaser's financial institu- 
tion 3, and the process result is checked in step 6624. 
If the process result is normal, then the provisional set- 
tlement money information received from the process- 40 
ing unit of the purchaser's financial institution 3 is stored 
in the provisional settlement money management DB 
6300 using the provisional settlement money ID 6301 
as a key in step 6626. In step 6628, the provisional set- 
tlement money issue balance 6203 in the money man- 45 
agement DB 6200 is updated (b = b + b1 ). If the process 
result is not normal in step 6624, an error process is 
performed in step 6630. 

Next, a goods order process 6650 in which a goods 
order is placed and provisional settlement money is 50 
transferred to a seller is described by referring to FIG. 
75. 

After receiving goods information from the seller's 
processing unit 2 in step 6652 in the goods order proc- 
ess 6650, goods are selected in step 6654. In step 6656, 55 
a goods order request containing the number of goods, 
the amount of the orders, a payment method, personal 
information, etc. added to goods information is transmit- 



ted to the seller's processing unit 2. 

Then, the process result (detail of purchase) is re- 
ceived from the seller's processing unit 2 in step 6660. 
The process result is checked in step 6662. If the result 
is normal, the provisional settlement money issue proc- 
ess is performed in step 6664. The personal identity 
confirmation information is set in the provisional settle- 
ment money information in step 6666, and the provision- 
al settlement money is transmitted to the seller's 
processing unit 2 in step 6668. 

The process result is received from the seller's 
processing unit 2 in step 6672. The process result is 
checked in step 6674. If the result is normal, a goods 
purchase record is generated in the goods purchase 
management DB 6100 using the payment ID 6101 as a 
key in step 6676. In steps 6662 and 6674, if the process 
result is not normal, an error process is performed in 
step 6678. 

Next, a goods receipt and return-of-goods process 
6700 is described by referring to FIG. 76 as a function 
of issuing a final settlement admission request based 
on the confirmation of goods. 

In the goods receipt and return-of-goods process 
6700, goods are received in step 6701 , and the contents 
of the goods are confirmed in step 6702. If the goods 
are correctly delivered according to the order, final set- 
tlement admission information is input in step 6704, and 
is transmitted to the processing unit at the purchaser's 
financial institution 3 in step 6706. 

Then, the process result is received from the 
processing unit at the purchaser's financial institution 3 
in step 671 0. The process result is checked in step 671 2. 
If it is normal, then a final settlement admission record 
is generated in the final settlement admission request 
management DB 6500 using the payment ID 6101 as a 
key and final settlement admission information such as 
the final settlement admission request date and time 
6504, etc. is set in step 6716. 

On the other hand, if the goods are defective, then 
a return-of-goods request is transmitted to the deliver- 
er's processing unit 7 in step 6718. In step 6722, a proc- 
ess result is received from the deliverer's processing 
unit 7, and the process result is checked in step 6724. 
If the result is normal, then a return-of-goods request 
record is generated in the return-of-goods request man- 
agement DB 6600 using the payment ID 6101 as a key 
in step 6725. In step 6724, the first third-party return-of- 
goods certification indicating that the return-of-goods 
process has been successfully performed when the 
goods are passed to the deliverer is received. 

Then, in step 6728, the first third-party return-of- 
goods certification is set in the first third-party return-of- 
goods certification 6606 in the return-of-goods request 
management DB 6600, and a provisional settlement 
cancellation request provided with the first third-party 
return-of-goods certification is transmitted to the 
processing unit at the purchaser's financial institution 3. 
The process result is received from the processing unit 
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at the purchasers financial institution 3 in step 6732, 
and the process result is checked in step 6734. If the 
result is normal, then the provisional settlement cancel- 
lation request 6607 in the return-of-goods request man- 
agement DB 6600 is set as 'issued' in step 6736 : and 
its date and time is set. If the process results are not 
normal in steps 671 2, 6724, and 6734, an error process 
is performed in step 6738. 

Next, the seller's processing unit 2 is described be- 
low by referring to FIG. 77 and subsequent figures. 

The seller's processing unit 2 is provided for per- 
forming operations from order acceptance to settlement 
and managing ret urn -of -goods when a seller sells 
goods. This unit has the following functions. 

First, an order from a purchaser of goods is accept- 
ed, money information containing the provisional settle- 
ment information from the purchaser is accepted, and a 
request is issued to make final settlement after the 
goods are transmitted to a goods receiver. 

Second, after a receiver has received goods, it is 
monitored whether or not a final settlement admission 
request or a return-of-goods request has been issued. 
If a final settlement admission request or a return-of- 
goods request is not issued within a predetermined pe- 
riod, a third-party delivery certification information indi- 
cating that the receiver has received the goods is added 
as authentication information, thereby issuing as a sub- 
stitute a final settlement admission request. 

Third, a cancellation request notification relating to 
return of goods is accepted, a provisional settlement 
cancellation request is issued in response to the can- 
cellation request notification, and a return-of-goods 
claim request is issued based on a confirmation of the 
contents of returned goods when the returned goods are 
not normal. 

To attain the above described functions, the seller's 
processing unit 2 is designed as shown in FIG. 77. The 
seller's processing unit 2 comprises an operation control 
unit 7010 for controlling the entire system; a communi- 
cations control unit 7020 for line-connection to each of 
the purchaser's processing unit 1 , the processing units 
at the purchaser's financial institution 3 and 4, the trans- 
action management device 5, the deliverer's processing 
units 6 and 7; a database control unit 7040 for controlling 
each database; a sales management process unit 7600 
for performing each process of the seller's processing 
unit 2; an input/output device 7030; and memory 7050. 

The database control unit 7040 controls and man- 
ages a goods management DB 7100, a sales manage- 
ment DB 7200, a provisional settlement money man- 
agement DB 7300, a final settlement request manage- 
ment DB 7400, a return-of-goods management DB 
7500, and a digital contents management DB 7550 as 
shown in FIG. 77. 

A sales management process unit 7600 comprises 
and performs the processes of a goods order accept- 
ance, money information acceptance, and final settle- 
ment request process 7610; a digital contents transmis- 



sion process 7700; a final settlement site monitor and 
final settlement admission substitution process 7750; a 
returned goods acceptance process 7850, a cancella- 
tion request acceptance process through return of dig- 
5 ital contents 7900; a cancellation process through return 
of goods 7950; and an execution term monitor and non- 
execution notification process 8000 as shown in FIG. 
77. 

FIG . 78 shows the concept indicating the correlation 
10 between databases managed by the database control 
unit 7040. 

The goods management DB 7100 contains the in- 
formation for management of the goods to be sold 
among which digital contents are managed by the digital 

is contents management DB 7550. 

The ordered goods are managed by the goods code 
of the goods management DB 7100. The order informa- 
tion is managed by the sales management DB 7200. 
The sales management DB 7200 contains provisional 

20 settlement money management information, final settle- 
ment request management information, and return-of- 
goods management information for use in money infor- 
mation management, final settlement management, 
and return-of-goods management required for sales 

25 management. The provisional settlement money man- 
agement information is pointer information to the provi- 
sional settlement money management DB 7300. The fi- 
nal settlement request management information is 
pointer information to the final settlement request man- 

30 agement DB 7400. The return-of-goods management 
information is pointer information to the return-of-goods 
management DB 7500. 

Each database is described in detail. 

The goods management DB 7100 stores a goods 

35 code 7 1 01 as a key; a goods classification 7 1 02 for iden- 
tifying goods, digital contents, etc. ; a goods name 71 03; 
goods sales information 7104; and a digital contents 
management ID 7105. The goods sales information 
7104 contains the number of goods stocks, the sales 

40 price, the site monitor term for goods receipt confirma- 
tion, the site monitor term for a return-of-goods claim, 
an average number of days for delivery, and the number 
of days for return-of-goods claim acceptance, and is in- 
herited by the goods purchase information 5305 and 

45 5406 of the purchaser's processing unit 1. The digital 
contents management ID 7105 is link information to the 
digital contents management DB 7550. 

FIG. 80 shows the sales management DB 7200. A 
payment ID 7201 is key data to money information man- 

50 agement, final settlement management, and return-of- 
goods management. A goods code 7202, an amount of 
bill 7203, order information 7204, an order date and time 
7204', purchaser information 7205, and authentication 
7206 are general goods order data. A payment method 

55 classification 7207 is a payment method specified by a 
purchaser when he or she places an order (for example, 
settlement account money, provisional settlement mon- 
ey, etc.). 
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Provisional settlement money management infor- 
mation 7208 is pointer information for use in manage- 
ment of payment money information based on the pay- 
ment method classification 7207, and points to a record 
of the provisional settlement money management DB 
7300. A shipping date and time 7210, a purchaser re- 
ceipt date and time 7211 , deliverer information 7212, 
and authentication 7213 contained in shipping informa- 
tion 7209 are information relating to the delivery of 
goods, and provided by a deliverer Ret urn -of -goods 
management information 7214 is pointer information 
generated when ret urn-of -goods arises, and points to a 
record of the ret urn -of- goods management DB 7500. Fi- 
nal settlement request management information 7215 
is pointer information for management of a final settle- 
ment request, and points to a record of the final settle- 
ment request management DB 7400. An encryption key 
721 6 and a decryption key 7217 of digital contents key 
information are information used when digital contents 
are sold. 

FIGs. 81 A and 81 B show the provisional settlement 
money management DB 7300 and the final settlement 
request management DB 7400 respectively. 

First, the provisional settlement money manage- 
ment DB 7300 is a database for storing money informa- 
tion received from the purchaser when goods are or- 
dered. The database stores a payment ID 7301 , a mon- 
ey type 7302 (either settlement account money or pro- 
visional settlement money), a receipt date and time 
7303, and payment money information 7304. In the in- 
formation, the payment money information 7304 de- 
pends on whether it is provisional settlement money or 
settlement account money as shown in the second and 
third rows shown in FIG. 81 A. 

The second row shows the provisional settlement 
money, and contains a provisional settlement money ID 
7311, a payment ID 7312 (the same as 7301), an 
amount 731 3, an issue date and time 731 4, goods pur- 
chase information 7315, and issuing financial institution 
information 7316. The entire provisional settlement 
money has a blind signature by issuing financial institu- 
tion (purchaser's financial institution). The third row 
shows the settlement account money (electronic mon- 
ey). Most of the items, that is, 7333, 7334, 7335, 7336, 
and 7337 are based on the provisional settlement mon- 
ey, but the settlement account money is different from 
the provisional settlement money in that the money ID 
contains a source ID 7331 and a child ID 7332 (addi- 
tional ID), and that the entire blind signature is executed 
by the purchaser. 

The final settlement request management DB 7400 
is a database generated when a money information final 
settlement request including received provisional settle- 
ment information is issued to the financial institution. As 
shown in FIG. 81 B, a payment ID 7401 is a key as in 
other databases. The final settlement financial institu- 
tion information is required when a final settlement re- 
quest is issued. When a request for receipt of transfer 



is issued to a purchaser's financial institution, the infor- 
mation about the financial institution and payee informa- 
tion (seller's financial institution and account informa- 
tion) is set in receipt-of -transfer requesting financial in- 
5 stitution information 7402. When a collection execution 
request is issued to the seller's financial institution, the 
information about the purchaser's financial institution of 
a collection destination, the information about the sell- 
er's financial institution, and the information about the 
10 account to which money is transferred are set in execu- 
tion requesting financial institution information 7403. A 
date and time corresponding to each process is set in 
each of a final settlement request date and time 7404 
and a final settlement completion date and time 7405. 

On the other hand, if goods are returned., a provi- 
sional settlement or final settlement cancellation proc- 
ess is performed. To manage the process, provisional 
settlement cancellation information 7406, a provisional 
settlement cancellation request date and time 7407, fi- 
nal settlement cancellation information 7408, and a final 
settlement cancellation request date and time 7409 are 
stored. 

The return-of-goods management DB 7500 is de- 
scribed below by referring to FIG. 82. 

The return-of-goods management DB 7500 is gen- 
erated when returned goods are delivered to a seller 
through a return-of-goods request from a goods receiver 
to a deliverer, and used for management in the future. 
Return-of-goods information 7501 , a purchaser's (or re- 
ceiver's) return-of-goods request date and time 7502, 
deliverer information 7503 and authentication of the de- 
liverer 7504, and seller's returned goods receipt date 
and time 7505 contained in the database are basic in- 
formation of the second third-party ret um-of -goods cer- 
tification issued by a deliverer. The seller receives re- 
turned goods, confirms the contents of the returned 
goods, and should notify the processing unit at the pur- 
chaser's financial institution 3 of a return-of-goods ad- 
mission or a return-of-goods claim. 

Each of the contents of the corresponding notifica- 
tions and their dates and times are set in return-of-goods 
admission information 7506 and its request date and 
time 7507, and return-of-goods claim information 7508 
and its request date and time 7509. If the seller admits 
the return-of-goods, then the processing unit at the pur- 
chaser's financial institution 3 performs a provisional 
settlement cancellation process under a provisional set- 
tlement state. If a final settlement has been completed, 
then a final settlement cancellation process is per- 
formed. 

The process result is set in the provisional settle- 
ment cancellation information 7406 and its request date 
and time 7407 or the final settlement cancellation infor- 
mation 7408 and its request date and time 7409 in the 
final settlement request management DB 7400 shown 
in FIG. 81 B. 

FIG. 83 shows the digital contents management DB 
7550. In the information in the goods management DB 
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7100, information relating to the digital contents is man- 
aged in the digital contents management DB 7550. 

The digital contents management DB 7550 contains 
a digital contents management ID 7551 for linking to the 
goods management DB 7100, a digital contents classi- 
fication code 7552, digest information 7553, encryption 
identification type 7554, and contents goods information 
7555. The encryption identification type 7554 specifies 
an encryption/decryption system of digital contents. The 
digital contents are encrypted by the system specified 
by the encryption identification type 7554 and transmit- 
ted to the purchaser. Then, after a purchase is deter- 
mined, the purchaser decrypts it using a decryption key 
transmitted from the seller. 

Next, the procedure of the processes 7610 through 
8000 performed by the sales management process unit 
7600 is described below by referring to the process flow 
shown in and after FIG. 84. 

First, the goods order acceptance, money informa- 
tion acceptance, and final settlement request process 
7610 is described below as a function of accepting a 
goods order and money and issuing a final settlement 
request. 

The procedure of the process 7610 is shown in 
FIGs. 84 and 85. In the process 7610, a goods order is 
first accepted from the purchaser's processing unit 1 in 
step 7611, and the contents received are confirmed in 
step 761 2. If the contents of the goods order is correct 
in step 7614, the goods management DB 7100 is re- 
ferred to through the goods code 7101 of ordered goods 
in step 7616. If there is a stock of corresponding goods 
in step 7618, an order acceptance notification is trans- 
mitted to the purchaser's processing unit 1 in step 7622. 

Then, provisional settlement money information is 
received from the purchaser's processing unit 1 in step 
7626, and the amount of the provisional settlement mon- 
ey and the validity of goods purchase information re- 
ceived are checked in step 7628. If it is determined in 
step 7629 that the check result is correct, then the pur- 
chaser is confirmed in step 7630. If the confirmation re- 
sult is correct in step 7632, then a payment ID is num- 
bered in step 7634, a sales management record is gen- 
erated in the sales management DB 7200 using the pay- 
ment ID 7201 as a key in step 7636, and a provisional 
settlement money record is generated in the provisional 
settlement money management DB 7300 using the pay- 
ment ID 7301 as a key in step 7538. Then, order accept- 
ance information is transmitted to the purchaser's 
processing unit 1 in step 7640. 

Then, it is determined in step 7642 whether or not 
ordered goods are digital contents. If they are physical 
goods, it is determined in step 7644 whether or not a 
delivery system exists. If yes, a goods delivery request 
is transmitted to the deliverer's processing unit 6 in step 
7646. If a process result is OK in step 7652 after the 
process result is received from the deliverer's process- 
ing unit 6 in step 7650, then the deliverer is requested 
to deliver the goods in step 7654 and receives third-par- 



ty delivery certification. In step 7656, shipping informa- 
tion such as date and time, etc. is set in the shipping 
date and time 7210 of the sales management DB 7200. 
If the ordered goods are digital contents in 7642, then a 
5 digital contents transmission process is performed in 
step 7700. 

Furthermore, in step 7660, provisional settlement 
money information is obtained from the provisional set- 
tlement money management DB 7300, and a final set- 
tlement request is transmitted to the processing unit of 
the purchaser's financial institution 3 in step 7662. A 
process result is received from the processing unit of 
the purchaser's financial institution 3 in step 7666, and 
the process result is checked in step 7668. If the process 
result is OK, then a record is generated in the final set- 
tlement request management DB 7400 using the pay- 
ment ID 7401 as a key in step 7670, and final settlement 
request information such as the final settlement request 
date and time 7404, etc. is set. 

If the contents are not correct in step 7614, if goods 
corresponding to the order are not found in step 7618, 
if a check result is not correct in step 7629, and if a con- 
firmation result is not correct in step 7632, then a notifi- 
cation that a goods order cannot be accepted is trans- 
mitted to the purchaser's processing unit 1 in step 7674. 
If the process results are NG in steps 7652 and 7668, 
then an error process is performed in step 7676. 

The procedure of the digital contents transmission 
process 7700 is described below by referring to FIG. 86. 
In step 7702, the digital contents transmission process 
7700 transmits the digest information about digital con- 
tents and encrypted digital contents. 

The digital contents transmission process 7700 re- 
fers to the digital contents management DB 7550 using 
the digital contents management ID 7105 of the goods 
management DB 7 1 00 as a key, and retrieves the digest 
information 7553 of the corresponding digital contents 
record. Furthermore, the contents goods information 
7555 is encrypted using the encryption key 7216 of the 
digital contents key information of the sales manage- 
ment DB 7200. These data are transmitted to the pur- 
chaser's processing unit 1 through the transaction man- 
agement device 5. 

Then, in step 7704, the decryption key 7217 of the 
digital contents key information in the sales manage- 
ment DB 7200 is transmitted to the transaction manage- 
ment device 5. Then, in step 7706, the shipping infor- 
mation 7209 is stored in the sales management DB 
7200, provisional settlement money information is ob- 
tained from the provisional settlement money manage- 
ment DB 7300 in step 7708, and a final settlement re- 
quest is transmitted to the transaction management de- 
vice 5. 

Next, a return-of-goods request is monitored, and a 
final settlement admission request is issued on behalf 
of a purchaser if the return-of-goods request is not is- 
sued within a predetermined period. The final settlement 
site monitor and final settlement admission substitution 
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process 7750 is described below by referring to FIG. 87 
as the above described function. 

In the final settlement site monitor and final settle- 
ment admission substitution process 7750, a sales man- 
agement record in the sales management DB 7200 is 
read once a day in step 7752, and the processes in and 
after step 7754 are performed. If the conditions of a final 
settlement are determined in step 7754, and if the final 
settlement has not been completed yet, then the condi- 
tions of a return-of-goods request is determined in step 
7756. If there is not return-of-goods request, it is deter- 
mined in step 7758 whether or not the monitor term (X 
days) has passed after shipment. If the monitor term has 
already passed, then the final settlement admission re- 
quest (as substitution) is issued to the processing unit 
of the purchaser's financial institution 3 with the third- 
party delivery certification received from a deliverer in 
step 7760. 

The returned goods acceptance process 7850 is 
described below by referring to FIG. 88. 

In the returned goods acceptance process 7850, re- 
turned goods are first received from the deliverer in step 
7852. The contents of the goods are confirmed, and a 
return-of-goods management record is generated in the 
retum-of-goods management DB 7500 in step 7854. If 
the goods returned is defective in step 7856 , then claim 
information is transmitted to the processing unit of the 
purchaser's financial institution 3 in step 7858, and the 
retum-of-goods claim information 7508 such as the 
claim request date and time 7509, etc. is set in the re- 
turn-of-goods management DB 7500 in step 7860. If the 
validity of goods is confirmed in step 7856, then the can- 
cellation process through return of goods 7950 is per- 
formed in step 7862. 

The cancellation process through return of goods 
7950 is described below by referring to FIG. 90. 

In the cancellation process through return of goods 
7950, a record in the return-of-goods management DB 
7500 is first read in step 7952, the final settlement re- 
quest management information 7215 in the sales man- 
agement DB 7200 is referred to in step 7954, and the 
final settlement request management DB 7400 is re- 
ferred to using the payment ID 7401 as a key, thereby 
confirming the conditions of the final settlement. If the 
final settlement completion date and time 7405 is set, 
then a final settlement cancellation (transfer of money 
to a purchaser's account) request is transmitted to the 
processing unit of the purchaser's financial institution 3 
in step 7955. If the final settlement completion date and 
time 7405 is not set, then the provisional settlement 
money management DB 7300 is referred to and it is de- 
termined whether or not there is a record of provisional 
settlement money corresponding to the payment ID. If 
there is a record of provisional settlement money, then 
a retum-of-goods admission and a provisional settle- 
ment cancellation request are transmitted to the 
processing unit of the purchaser's financial institution 3 
in step 7958. If there is no record of the provisional set- 



tlement money, then a return-of-goods admission is 
transmitted to the processing unit of the purchaser's fi- 
nancial institution 3 in step 7960. In step 7962, the 
record in the return-of-goods management DB 7500 is 
s updated. 

The description of the procedure of the seller's 
processing unit 2 not described yet is added. The fol- 
lowing procedure of the unit should be provided as a 
preferred embodiment of the present invention. 

FIG. 89 shows the procedure of the cancellation re- 
quest acceptance process 7900 through the return of 
digital contents. In the cancellation request acceptance 
process 7900, a request message about the digital con- 
tents is received from the transaction management de- 
vice 5 in step 7902, and a return-of-goods management 
record is generated in the return-of-goods management 
DB 7500. Then, the contents of the request is deter- 
mined in step 7904. If it is a digital contents re-transmis- 
sion request, then the encrypted digital contents trans- 
mitted to the purchaser's processing unit 1 are re-trans- 
mitted to the transaction management device 5. A de- 
cryption process result of digital contents is received 
from the transaction management device 5 in step 79 1 0, 
and is confirmed in step 7912. If a decryption process 
is not correctly performed in the transaction manage- 
ment device 5, and a non-encrypted digital contents re- 
transmission request is issued in step 7914, then non- 
encrypted digital contents are re-transmitted after en- 
crypting them using an encryption key between the sell- 
er's processing unit 2 and the transaction management 
device 5 in step 7916. If a confirmation process result 
of the digital contents by the transaction management 
device 5 is received in step 7920 and the result is OK in 
step 7922, then the process terminates. If the cancella- 
tion request is received in steps 7904 and 791 4 : and if 
the process result is NG in step 7922, then it is deter- 
mined in step 7924 whether or not the provisional set- 
tlement cancellation request can be admitted. If yes, the 
cancellation process through return-of-goods 7950 is 
performed in step 7928. If not, the return-of-goods claim 
information is transmitted to the transaction manage- 
ment device 5 in step 7926, and the claim request date 
and time 7509 of the return-of-goods management DB 
7500 is set. 

Finally, the configuration in which it is determined 
whether or not goods have been shipped is described 
below by referring to the process flow shown in and after 
FIG. 91. 

First, the goods shipment execution term, that is, 
payment condition information, is monitored. If goods 
are not shipped within an execution term, then the pay- 
ment condition information is transmitted as authentica- 
tion information to issue a transaction cancellation re- 
quest. The procedure of the execution term monitor 
process 7970 is described as the above described func- 
tion. The execution term monitor process 7970 is per- 
formed in the purchaser's processing unit 1 or in a 
processing unit provided at a goods receiver. 
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FIGs. 91 and 92 are flowcharts showing the execu- 
tion term monitor process 7970. In this execution term 
monitor process 7970, an input of the execution term 
requested by the purchaser is first accepted in step 
7972, and the seller's processing unit 2 is inquired in 5 
step 7974 whether or not the execution term can be fol- 
lowed. If the inquiry result is NG in step 7976, then the 
purchaser is inquired in step 7978 whether or not the 
execution term can be changed. If the term can be 
changed, then a re-entry of the execution term is accept- 
ed in step 7980, and the processes in and after 7974 
are repeated. If the change is not accepted, the process 
terminates. 

If the inquiry result is OK in step 7976, then the ex- 
ecution term is set in the provisional settlement money 
in step 7982, and it is transmitted to the seller's process- 
ing unit 2. Then, it is determined in step 7984 whether 
or not an object for which the execution term is to be 
monitored exists. If yes, then the provisional settlement 
money corresponding to the object is searched in step 
7986, and the date and time of the execution term set 
for the provisional settlement money is compared with 
the current date and time in step 7988. If the current date 
and time has not passed the date and time of the exe- 
cution term, then it is checked in step 7990 whether or 
not there is an input for confirmation of the execution. 

If yes, confirmation information such as the confir- 
mation date and time, the name of the confirmor etc. is 
set in the provisional settlement money in step 7992, 
and the processes in and after step 7984 are repeated. 
If there is no input for confirmation, then the processes 
in and after step 7984 are repeated. When no monitor 
objects exist in step 7984, the process terminates. 

If the current date and time has passed the date and 
time of the execution term in step 7988, then the issuing 
financial institution is informed of the provisional settle- 
ment cancellation request together with the provisional 
settlement money for which the execution term has 
passed in step 7994. Then, in step 7996, the cancella- 
tion requested information containing a request date 
and time, etc. is set in the provisional settlement money 
in step 7996, thereby terminating the process. 

Then, a goods order is accepted from a purchaser, 
provisional settlement money settled through confirma- 
tion notification that the goods have been delivered is 
accepted, the execution term of the goods delivery, that 
is, payment condition information, is monitored. If the 
goods are not delivered within an execution term, it is 
notified to a purchaser or a goods receiver The proce- 
dure of the execution term monitor and non-execution 
notification process 8000 shown in FIG. 77 performed 
by the seller's processing unit 2 is described below as 
the above described function. 

FIGs. 93 and 94 are flowcharts showing the execu- 
tion term monitor and non-execution notification proc- 
ess 8000. In the process 8000, transmission information 
is first accepted from a purchaser or a goods receiver 
in step 8002, and a seller is inquired in step 801 2 wheth- 



er or not goods can be shipped within the execution term 
if the transmitted information refers to an inquiry about 
the confirmation of the execution term in step 8004. If 
the goods can be shipped, the processes in and after 
step 8016 are performed. If they cannot be shipped, 
then the execution term change request is issued to the 
information transmitter, thereby terminating the proc- 
ess. 

If the transmission information is not an inquiry 
about the confirmation of the execution term in step 
8004, but is provisional settlement money in step 8006, 
then it is checked whether or not the execution term is 
set in step 8008. If the execution term is set, then it is 
checked in step 8010 whether or not there is confirma- 
tion information about the execution term. If there is con- 
firmation information, then the processes in and after 
step 8016 are performed. 

If the execution term is not set in step 8008, the 
processes in and after step 8016 are performed. If there 
is no confirmation information in step 8010, then the 
processes in and after step 8012 are performed. If the 
transmission information is not provisional settlement 
money in step 8006, then the process terminates. 

In step 8016, the transmitter is informed that the 
transmitted information has been correctly received. 
Then, in step 801 8, it is determined whether or not there 
is an execution term monitor object. If yes, the provision- 
al settlement money corresponding to the object is 
searched in step 8020, and the execution term date and 
time set for the provisional settlement money is com- 
pared with the current date and time in step 8022. If the 
current date and time has not passed the date and time 
of the execution term, then it is checked in step 8024 
whether or not there is an input indicating that the goods 
shipment has been executed. 

If there is a corresponding input, then the execution 
completion information such as an execution date and 
time, the name of an execution confirmor, etc. is set in 
the provisional settlement money in step 8026, a corre- 
sponding final settlement request process is performed 
in step 8028, and the processes in and after step 8018 
are repeated. If there is no corresponding input, then the 
processes in and after step 8018 are repeated. If there 
is no monitor object in step 8018, then the process ter- 
minates. 

If the current date and time has passed the date and 
time of the execution term in step 8022, then the non- 
execution information such as the non-execution confir- 
mation date and time, the reason for non-execution, the 
name of a non-execution confirmor, etc. is set in provi- 
sional settlement money in step 8030, and the transmit- 
ter is informed that goods have not been shipped in step 
8032, thereby terminating the process. 

In the above described embodiment of the present 
invention, the payment is made for the sales of products 
such as physical goods and digital contents, etc. How- 
ever, similar systems can be applicable when payment 
is made for services. In this case, a service is an object 
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item for which payment is to be made. 

Each device or unit according to the present em- 
bodiment can be designed using the information 
processing unit (computer) as shown in FIG. 95. The 
information processing device shown in FIG. 95 com- s 
prises a CPU (central processing unit) 8101, memory 
8102, an input device 8103, an output device 8104, an 
external storage device 8105, a media drive device 
8106, and a network connection device 8107. These 
components are interconnected through a bus 81 08. 10 

The memory 8102 stores a program and data used 
for a process. The memory 8102 can be, for example, 
ROM (read only memory), RAM (random access mem- 
ory), etc. The CPU 8101 performs a necessary process 
by executing the program using the memory 8102. '5 

The input device 8103 is, for example, a keyboard, 
a pointing device, a touch panel ; etc., and can be used 
when inputting an instruction and information from a us- 
er. The output device 8104 is, for example, a display, a 
printer, etc. and can be used when outputting an inquiry, 20 
a process result, etc. to a user. 

The external storage device 8105 is, for example, 
a magnetic disk device, an optical disk device, a mag- 
neto-optical disk device, etc. The above described pro- 
gram and data are stored in the external storage device 25 
81 05, and loaded onto the memory 81 02 for use as nec- 
essary. The external storage device 8105 can also be 
used as a database of various types. 

The media drive device 8106 drives a portable stor- 
age medium 8109, and accesses the stored contents. 30 
The portable storage medium 8109 can be any compu- 
ter-readable storage medium such as a memory card, 
a floppy disk, CD-ROM (compact disk read only mem- 
ory), an optical disk, a magneto-optical disk, etc. The 
above described program and data are stored in the 35 
portable storage medium 8109, and loaded onto the 
memory 8102 for use as necessary. 

The network connection device 8107 communi- 
cates with other devices through an optional network 
(line) such as a LAN (local area network), etc., and con- 40 
verts data for communications. When it is necessary, the 
above described program and data are received from 
an external device, and they are loaded onto the mem- 
ory 8102 to be used. 

FIG. 96 shows computer-readable storage media 45 
capable of providing the program and data for the infor- 
mation processing device shown in FIG. 95. The pro- 
gram and data stored in the portable storage medium 
8109 and an external database 8110 are loaded onto 
the memory 81 02. The CPU 81 01 executes the program so 
using the data and performs a necessary process. 

As described above, according to the present in- 
vention, a payer (purchaser of goods, service requester, 
etc. ) can indicate his or her payment capacity to the pay- 
ee (seller, service provider, etc.) when he or she pur- 55 
chases goods or requests a service by informing the 
payee of the money information including the informa- 
tion about provisional settlement settled at a notification 



that an object item of the payment (providing goods, 
services, etc.) has been executed. The payee can se- 
cure the expenses for the goods or services according 
to the money information. Therefore, the payee can 
solve the problem of a collection risk about goods and 
services. 

A payer or a confirmor who confirms the object item 
of payment admits final settlement after confirming the 
contents (color, size, pattern, quality, manufacturer's 
name, type, authentication, etc.) of ordered goods and 
received goods after receipt of the goods when the 
goods are purchased. Therefore, the purchaser can ob- 
tain desired goods. When the purchaser orders a serv- 
ice, the final settlement is admitted after confirming the 
result of the work performed by a service provider 
(white-ant exterminating, field work of cleaning and 
washing, repairing a house, etc.), thereby easily avoid- 
ing insufficient working. Therefore, both payer and pay- 
ee can be free of risk and the settlement process can 
be successfully performed. 

With the above described configuration, a payee 
can confirm with authentication of the issuing financial 
institution that the issuing financial institution has se- 
cured in the account of the payer the money information 
containing the provisional settlement information settled 
upon receipt of the confirmation notification that the ob- 
ject item for which payment is to be made has been ex- 
ecuted. Therefore, goods, services, etc. can be provid- 
ed without depending on a payer's personal credit. 

Since the money information containing the provi- 
sional settlement information includes the information 
about an object item for which payment is made, the is- 
suing financial institution can confirm necessary infor- 
mation according to more detailed information at the fi- 
nal settlement and can effectively avoid the occurrences 
of accidents in the settlement performed in response to 
an illegal settlement request. Furthermore, it prevents a 
payer from using the money information containing the 
provisional settlement information for other uses. 

According to the present invention, since the pay- 
ment object information is encrypted (blinded) using an 
encryption key so that only the issuing financial institu- 
tion can decrypt the information, the money information 
can be prevented from being illegally copied by a third 
party for other uses. 

Furthermore, according to the present invention, a 
payer pays to a payee after the payer generates provi- 
sional settlement information using electronic money 
having information for identifying whether or not the pro- 
visional settlement information is contained. Final set- 
tlement is made after the payer or a confirmor has con- 
firmed the contents of the goods or services provided 
from the payee. Therefore, both payer and payee are 
free of risk, and the settlement process can be success- 
fully performed. The payer determines at the transfer of 
electronic money whether it is paid as final settlement 
electronic money without provisional settlement infor- 
mation or as provisional settlement electronic money 
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with the generated provisional settlement information. 
Therefore, the electronic money can be paid effectively 
and safely depending on payment conditions. 

According to the present invention, when the money 
information containing the provisional settlement infor- $ 
mation is stored in a portable storage medium such as 
a portable card, etc., a payer can transmit payment to a 
payee online through a network: etc. when purchasing 
goods : or can pay by directly providing the portable stor- 
age medium. As a result, the convenience in payment 10 
can be improved and the opportunities that the goods 
are sold can be extended. 

According to the present invention, the portable 
storage medium can be issued from a terminal such as 
an ATM, etc. connected to an issuing financial institu- *5 
tion. As a result, an issue of a forged portable storage 
medium can be suppressed. Furthermore, since a port- 
able storage medium can be issued by any terminal unit 
without designating a specific location, a payer (a per- 
son who requests an issue of a portable storage medi- 20 
um) can obtain the medium at any time when a terminal 
unit is operable even after the windows of the issuing 
financial institution are closed. 

According to the present invention a payee puts the 
portable storage medium transferred as provisionally 25 
settled money information from a payer into the terminal 
unit such as an ATM, etc. connected to the issuing fi- 
nancial institution to issue a final settlement request. 
Therefore, even a payee not provided with a processing 
unit connected through a network can process a trans- 30 
action using the provisional settlement system. 

According to the present invention, when a portable 
storage medium is issued from a terminal unit such as 
an ATM, etc. connected to the issuing financial institu- 
tion, it is indicated whether or not an automatic collection 35 
is performed upon completion of a process. If it is indi- 
cated that a portable storage medium is automatically 
collected, it can be collected upon confirmation of a 
process, thereby avoiding illegal operations and saving 
resources by re-using the portable storage medium. 40 

Furthermore, according to the present invention, an 
illegal use of a portable storage medium can be avoided 
by writing information which prohibits the re-use of the 
medium after a process is completed even if the auto- 
matic collection is not performed on the medium. 45 

According to the present invention, since a final set- 
tlement request can be accepted from a payee but final 
settlement cannot be made without a final settlement 
admission from a payer. Therefore, a payer's payment 
risk can be avoided. so 

According to the present invention, when a payee 
issues a final settlement request to a payer's financial 
institution, the payee specifies, as request for receipt of 
transfer information when final settlement is made, the 
transfer destination information addressed to the pay- ss 
ee's financial institution containing the payee's account, 
or the payee's electronic wallet information. Thus, when 
the final settlement is made, the transfer is automatically 



executed to the payee specified in the request for receipt 
of transfer information. 

According to the present invention, a transaction is 
processed through an intermediate for transmission 
(transaction management device, etc.). Therefore, a 
transmitter of transaction information need not receive 
an encryption key of a receiver or send the transmitter's 
encryption key. Since the transmitter transmits a mes- 
sage after encrypting it using a unique encryption key 
between a transmission intermediate and the transmit- 
ter, the transmitter need not transmit or receive an en- 
cryption key or a decryption key to or from the receiver. 
Therefore, there is no risk that a third party may read 
the transaction information. Furthermore, the transmit- 
ter can easily manage the encryption key, thereby large- 
ly improving the security. 

Furthermore, according to the present invention, a 
transmission intermediate decrypts an encrypted elec- 
tronic message transmitted from the transmitter using a 
unique decryption key between the intermediate and the 
transmitter thereby easily authenticating the transmit- 
ter. 

According to the present invention, since a receiver 
receives an electronic message encrypted using a 
unique encryption key between the intermediate and the 
receiver, the receiver need not consider the encryption 
key of the transmitter. Additionally, the receiver can eas- 
ily manage the encryption key, thereby largely improving 
the security. 

Furthermore, according to the present invention, 
since transaction conditions cannot be confirmed if a 
transaction is processed only between the parties con- 
cerned, a transaction management device is provided. 
The entire process of the transaction can be correctly 
performed by transmitting and receiving the transaction 
information by a payer, a payee, and a financial institu- 
tion through the transaction management device. 

According to the present invention, when the trans- 
action management device manages transaction infor- 
mation, it manages the information with authentication 
of a transmitter thereby avoiding a refusal of the trans- 
mitter's personal identity or the transaction. 

Furthermore, according to the present invention, 
when a payee has to issue a transaction cancellation 
request to the transaction management device due to 
an unsuccessful transaction, the transaction manage- 
ment device monitors the occurrence of a transaction 
cancellation request process performed by the payee. 
Therefore, the payer need not check the transition can- 
cellation conditions. 

According to the present invention, the transaction 
management device manages the period from the oc- 
currence of a cancellation event predetermined for each 
transaction to an issue of a cancellation request. If the 
cancellation request from the payee is not issued within 
the period, then the device performs the cancellation re- 
quest process on behalf of the payee. As a result, the 
cancellation process can be performed without delay 
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Furthermore, according to the present invention, 
the transaction management device monitors based on 
the date and time on which a receiver receives goods 
whether or not the receiver has issued a final settlement 
admission request and whether or not the goods were 
returned. Therefore, the transaction conditions such as 
final settlement through provisional settlement, cancel- 
lation of a transaction, etc. can be correctly recognized. 

Furthermore, according to the present invention, 
the transaction management device manages the peri- 
od from the receipt of goods to an issue of a final settle- 
ment admission request or a return-of-goods request. If 
the receiver does not issue a final settlement admission 
request or a return-of-goods request within the period, 
then it issues a final settlement admission request on 
behalf of the receiver. Therefore, the transaction can be 
processed without delay after receipt of goods until a 
final settlement admission request. 

Furthermore, according to the present invention, 
when a receiver returns goods and a notification that a 
retum-of-goods procedure has been followed, the trans- 
action management device issues a transaction cancel- 
lation request on behalf of the receiver. Therefore, the 
cancellation process can be performed without delay af- 
ter return of goods. 

Furthermore, according to the present invention, a 
deliverer's processing unit receives a delivery request 
from a payee, manages a receipt signature of a delivery 
destination, and generates delivery certification infor- 
mation including a payment ID related to delivered 
goods, thereby certifying the fact that the goods have 
been delivered. 

Furthermore, according to the present invention, 
the deliverer's processing unit manages the signature 
of a requester when a returned goods delivery request 
is issued from a receiver, and generates delivery certi- 
fication information including a payment ID related to the 
goods to be returned, thereby certifying the fact that a 
retum-of-goods process has been started. 

Furthermore, according to the present invention, 
when the deliverer's processing unit delivers goods to 
be returned to a payee, it manages the receipt signature 
of a payee, and generates final return-of-goods certifi- 
cation information including a payment ID related to the 
goods to be returned. As a result, it certifies the fact that 
the returned goods have been delivered to the payee. 

According to the present invention, when a deliver- 
er's processing unit generates each of the delivery cer- 
tification information certifying that goods have been de- 
livered, the return-of-goods certification information cer- 
tifying that the returned goods have been accepted, and 
the final return-of-goods certification information certify- 
ing that the returned goods have been delivered to the 
payee, the information is entered in the transaction man- 
agement device. As a result, correct conditions in each 
of the transaction processes can be recognized. Fur- 
thermore, a transaction trouble can be avoided by using 
each certification information as the third-party admis- 



sion information. 

Furthermore, according to the present invention, 
the transaction management device manages the peri- 
od from a receiver's receipt of goods to an issue of a 

s final settlement admission request or a return-of-goods 
request. If no final settlement admission request or re- 
turn-of-goods request has been issued within the peri- 
od, then the transaction management device issues a 
final settlement admission request on behalf of the re- 

10 ceiver. At this time, since the final settlement admission 
request is issued as containing the delivery certification 
information of the deliverer's processing unit as authen- 
tication information, the process can be performed by 
the substitute at a higher reliability. 

*5 According to the present invention, after a receiver 
issues a return-of-goods request and the returned 
goods are delivered to a payee, the transaction man- 
agement device issues a cancellation request on behalf 
of the receiver with a final return-of-goods certification 

20 information of the deliverer's management device add- 
ed as authentication information. Thus, the process can 
be performed by a substitute at a higher reliability. 

Furthermore, according to the present invention, a 
receiver issues a cancellation request with the return- 

2S of-goods certification information added as authentica- 
tion information certifying that the return-of-goods re- 
quest has been accepted. As a result, the receiver can 
also issue a transaction cancellation request and the 
cancellation process can be quickly performed. 

30 Furthermore, according to the present invention, a 
payee manages the period after a receiver has received 
goods until a final settlement admission request or a re- 
turn-of-goods request is issued, and monitors whether 
or not a final settlement admission request or a retum- 

35 of-goods request has been issued. If neither of these 
requests have been issued, the payee issues a final set- 
tlement admission request including as authentication 
information the delivery certification information of a 
transaction management device which certifies that the 

40 goods have been delivered to the receiver. Therefore, 
the payee can issue a final settlement admission re- 
quest instead of the receiver, and can quickly perform a 
final settlement process. 

Furthermore, according to the present invention, 

45 the processing unit at a financial institution receives the 
final return-of-goods certification information certifying 
that the payee has received returned goods, receives a 
notification that there is a problem with the returned 
goods from the payee or the transaction management 

50 device, anticipates a case where a cancellation process 
cannot be performed, and manages the receipt period 
of a return-of-goods claim for each transaction. Then, it 
monitors whether or not a return-of-goods claim notifi- 
cation is issued within the period. Therefore, if there is 

55 a defect found in the goods returned from the good re- 
ceiver, then the cancellation process is reserved to 
avoid a trouble in the return-of-goods process. 

Furthermore, according to the present invention, 



53 



105 



EP 0 858 057 A2 



106 



when the processing unit at the financial institution re- 
ceives a notification that returned goods have been cor- 
rectly received from the payee who received the re- 
turned goods or the transaction management device, 
the cancellation process can be quickly performed with- 
out waiting for the expiry of the return-of-goods claim 
receipt period. 

Furthermore, according to the present invention, 
the transaction management device in the digital con- 
tents sales system manages a decryption key for digital 
contents on behalf of a payee, and passes the decryp- 
tion key at a demand from a payer. Therefore, the trans- 
action management device can correctly manage 
whether or not the digital contents have successfully 
reached the payer. 

Furthermore, according to the present invention, 
when the transaction management device transmits a 
decryption key for digital contents at a demand of a pay- 
er, it manages the signature of the payer, and generates 
the third party admission information, thereby avoiding 
the rejection of the payer. 

Furthermore, according to the present invention, 
when the transaction management device receives a 
notification from a payer that digital contents cannot be 
decrypted it obtains the digital contents transmitted from 
the payee to the payer, and compares them with the dig- 
ital contents from the payer. As a result, it can be mon- 
itored whether or not the digital contents of the payer 
have been illegally amended. 

Furthermore, when the transaction management 
device finds no defect in the digital contents as a com- 
parison result, then it decrypts the contents using a de- 
cryption key transmitted to the payer. Therefore, the va- 
lidity of the digital contents and the decryption key can 
be managed. 

Furthermore, according to the present invention, 
the transaction management device compares the de- 
crypted digital contents with the un-encrypted digital 
contents received from the payee, and correctly man- 
ages whether or not the decrypted digital contents have 
been illegally amended. 

Furthermore, according to the present invention, 
the transaction management device re-transmits a de- 
cryption key to a payer if there is a defect found in the 
decryption key as a result of the comparison. Therefore, 
the transaction of the digital contents can be performed 
without delay. 

Furthermore, according to the present invention, if 
the transaction management device finds as a compar- 
ison result a defect in the digital contents transmitted 
from the payee to the payer, then it transmits to the pay- 
ee a notification such as a cancellation request, etc. to 
stop the payment process by the payer, thereby per- 
forming a cancellation process without delay. 

Furthermore, according to the present invention, 
when the transaction management device finds as a 
comparison result a defect in the digital contents, the 
digital contents are re-transmitted tc the payer, thereby 



performing the transaction of the digital contents without 
delay. 

Furthermore, according to the present invention, a 
payer can be different from a confirmor (goods receiver, 
s service receiver, etc.) who confirms an object item for 
which payment is made. Therefore, using money infor- 
mation including provisional settlement information, 
presents can be transmitted to a family or a third party 
or a service of cleaning a house, etc. by a service pro- 
10 vider, can be easily presented on Mother's day or a spe- 
cial day such as a birthday. 

Furthermore, according to the present invention, a 
confirmor who confirms an object item for which pay- 
ment is to be made, can immediately issue a final set- 
tlement admission request after confirming the contents 
of the received goods or receiving a service. Therefore, 
the confirmor can make a final settlement (payment) 
more quickly than a payer who issues a final settlement 
admission request. Furthermore, the confirmor need not 
communicate with a payer for the final settlement ad- 
mission request. 

Furthermore, according to the present invention, 
the money information containing provisional settlement 
information can include as payment condition informa- 
tion the execution term about the object item for which 
payment is to be made. Therefore, it can be objectively 
checked or monitored whether or not goods can be de- 
livered by a predetermined deadline (within the execu- 
tion term), and whether or not a requested service has 
been performed within the execution term. 

Furthermore, according to the present invention, 
when a payee cannot deliver ordered goods or a re- 
quested service within an execution term for an object 
item for which payment is to be made, a payer or a con- 
firmor who confirms the object item for which payment 
is to be made can issue a cancellation request for the 
paid money information containing provisional settle- 
ment information. Therefore, a risk of a lost profit due to 
expiry can be avoided. A risk of a lost profit due to expiry 
refers to that goods and a service lose their values when 
they cannot be delivered or provided by a specified date 
such as a birthday, Mother's day, Christmas Eve, etc. 

Furthermore, according to the present invention, a 
transaction management device monitors the execution 
term, that is, payment condition information, of an object 
item for which payment is to be made. Therefore, if or- 
dered goods or requested services cannot be delivered 
or provided by the payee within the execution term, then 
the transaction management device can issue a cancel- 
lation request for paid money information containing 
provisional settlement information instead of the payer 
according to objective information. Furthermore, a pay- 
er or a confirmor who confirms an object item for which 
payment is to be made need not check or monitor as 
described above, and therefore even children and elder 
people can safely place an order for a service or goods. 

Furthermore, according to the present invention, a 
payee monitors the execution term, that is, payment 
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condition information, of an object item for which pay- 
ment is to be made. If ordered goods or requested serv- 
ices cannot be delivered or provided within the execu- 
tion term, then the payee notifies the payer or the con- 
firmor who confirms the object item for which payment 
is to be made. Therefore, the payer or the confirmor can 
issue a rapid cancellation request. 

The above described effects relate to the system 
and device according to the present invention. Similar 
effects can be expected when a storage medium ac- 
cording to the present invention is used. 

Claims 

1. A provisional settlement system comprising: 

means (1) for transferring money information, 
which is settled according to a notification of 
confirmation that an object item for which pay- 
ment is to be made has been executed, con- 
taining provisional settlement information to a 
payee; and 

means (3) for making final settlement for the 
money information based on the confirmation 
that the object item for which payment is to be 
made has been executed. 

2. The system according to claim 1 , wherein 

said money information containing the provi- 
sional settlement information is generated by an is- 
suing financial institution, and an amount of the 
money information is frozen in a balance of an ac- 
count of a payer in the issuing financial institution, 
and is non-transferable until the final settlement is 
made. 

3. The system according to claim 1 or 2, wherein 

said money information containing the provi- 
sional settlement information includes object infor- 
mation indicating the object item for which payment 
is to be made. 

4. The system according to claim 3, wherein 

said object information is assigned a blind sig- 
nature using an encryption key of an issuing finan- 
cial institution which is not public. 

5. The system according to any preceding claim, 
wherein 

said money information containing the provi- 
sional settlement information is stored in a portable 
storage medium (82). 

6. The system according to claim 5, wherein 

said portable storage medium is issued from 
a terminal unit (80, 80') connected to an issuing fi- 
nancial institution of a payer. 



7. The system according to claim 5 or 6, wherein 

said portable storage medium can be applied 
to a terminal unit connected to an issuing financial 
institution of the payee, and the terminal unit corn- 
s prises means (3010, 3020) for transmitting a final 
settlement request according to the provisional set- 
tlement information stored in the portable storage 
medium. 

10 8. The system according to claim 7, wherein 

said terminal unit comprises means (3003, 
3010) for collecting the portable storage medium af- 
ter the payee has issued the final settlement re- 
quest. 

is 

9. The system according to claim 7 or 8, wherein 

said terminal unit comprises means (3001, 
3010) for writing information inhibiting a re-use of 
the portable storage medium upon normal comple- 
20 tion of a process for the final settlement request. 

10. The system according to any preceding claim, fur- 
ther comprising: 

25 means (5300) for storing a final settlement re- 

quest from the payee; 

means (5300) for storing a final settlement ad- 
mission (permission) request from the payer; 
and 

30 means (5700) for performing the final settle- 

ment based on the stored final settlement re- 
quest and final settlement admission request. 

11. The system according to claim 10, wherein 

35 said final settlement request contains request 

for receipt of transfer information containing a trans- 
fer destination. 

12. The system according to any preceding claim, fur- 
40 ther comprising: 

a transaction management device (5) for me- 
diating transmission and receipt of transaction in- 
formation. 

45 13. The system according to claim 12, wherein 

said transaction management device com- 
prises transaction information management means 
(55) for storing the transaction information with au- 
thentication information about a transmitter. 

so 

14. The system according to claim 12 or 13, wherein 

said transaction management device com- 
prises means (1500) for monitoring a transaction 
cancellation request from the payee. 

55 

15. The system according to claim 14, wherein 

said transaction management device com- 
prises means (1500) for issuing a cancellation re- 
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quest on behalf of the payee when the transaction 
management device does not receive the cancella- 
tion request from the payee within a predetermined 
period. 

5 

16. The system according to any of claims 12 to 15, 
wherein 

said transaction management device com- 
prises means (1500) for monitoring whether or not 
one of a final settlement admission request and a 10 
return-of -goods request is issued by a goods re- 
ceiver after the goods receiver has received goods 
when the object item for which payment is to be 
made relates to goods. 

15 

17. The system according to claim 16 : wherein 

said transaction management device com- 
prises means (1500) for issuing the final settlement 
admission request on behalf of the goods receiver 
when neither of the final settlement admission re- 20 
quest and the return -of -goods request are issued 
within a predetermined period. 

18. The system according to claim 16, wherein 

said transaction management device com- 25 
prises means (1500) for issuing a transaction can- 
cellation request when a return-of -goods procedure 
is followed. 

19. The system according to any of claims 12 to 18, 30 
wherein 

said transaction management device com- 
prises: 

means (1500) for monitoring at least one of a 35 
final settlement admission request and a re- 
turn-of-goods request; and 
means (1500) for transmitting third-party deliv- 
ery certification information containing a pay- 
ment identifier relating to purchase of goods as <*o 
authentication information and issuing the final 
settlement admission request when none of the 
final settlement admission request and the re- 
turn-of-goods request are issued. 

45 

20. The system according to any of claims 12 to 19, 
wherein 

said transaction management device com- 
prises means (1500) for transmitting third-party re- 
turn-of -goods certification information containing a so 
payment identifier relating to purchase of goods as 
authentication information and issuing a transaction 
cancellation request. 

21. The system according to claim 20, further compris- ss 
ing: 

means (5700) for monitoring a return-of-goods 



claim notification from one of a seller and a 
transaction management device after the 
goods have been returned; and 
means (5700) for reserving a transaction can- 
cellation process when the return-of-goods 
claim notification is received within a predeter- 
mined period. 

22. The system according to claim 21 , further compris- 
ing: 

means (5700) for immediately performing the 
transaction cancellation process even within 
the predetermined period when a returned 
goods receipt notification is received from one 
of the seller and the transaction management 
device. 

23. The system according to any of claims 1 2, to 22, 
wherein 

said transaction management device com- 
prises: 

means (1 500) for monitoring an execution term, 
contained in payment condition information, of 
the object item for which payment is to be 
made; and 

means (1 500) for transmitting the payment con- 
dition information as authentication information 
and issuing a transaction cancellation request 
when the object item is not executed within the 
execution term. 

24. The system according to any preceding claim, 
wherein 

said object item for which payment is to be 
made relates to goods; and 
at least one of a purchaser and a receiver of 
the goods has means (6800, 7600) for trans- 
mitting third-party return-of-goods certification 
information containing a payment identifier re- 
lating to purchase of the goods as authentica- 
tion information, and issuing a transaction can- 
cellation request. 

25. The system according to claim 24, further compris- 
ing: 

means (5700) for monitoring a return-of-goods 
claim notification from one of a seller and a 
transaction management device after the 
goods are returned; and 
means (5700) for reserving a transaction can- 
cellation process when the return-of-goods 
claim notification is received within a predeter- 
mined period. 
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26. The system according to claim 25, further compris- 
ing: 

means (5700) for immediately performing the 
transaction cancellation process even within the 
predetermined period when a returned goods re- 
ceipt notification is received from one of the seller 
and the transaction management device. 

27. The system according to any preceding claim, 
wherein 

said payee has: 

means (7600) of monitoring at least one of a 
final settlement admission request and a re- 
turn-of-goods request; and 
means (7600) for issuing the final settlement 
admission request by transmitting third-party 
delivery certification information, as authenti- 
cation information, containing a payment iden- 
tifier related to purchase of goods when one of 
the final settlement admission request and the 
return -of-goods request is not issued within a 
predetermined period. 

28. The system according to any preceding claim, 
wherein 

a payer who transfers the money information 
containing the provisional settlement information to 
the payee is different from a confirmor who confirms 
the object item executed by the payee. 

29. The system according to any preceding claim, fur- 
ther comprising: 

means (5300) for storing a final settlement re- 
quest from the payee; 

means (5300) for storing a final settlement ad- 
mission request from a confirmor who confirms 
the object item for which payment is to be 
made; and 

means (5700) for making the final settlement 
based on the stored final settlement request 
and final settlement admission request. 

30. The system according to any preceding claim, 
wherein 

said money information containing the provi- 
sional settlement information includes payment 
condition information indicating an execution term 
of the object item for which payment is to be made. 

31. The system according to claim 30, further compris- 
ing: 

means (6800) for issuing a transaction can- 
cellation request by transmitting the payment con- 
dition information as authentication information 
from one of a payer and a confirmor who confirms 
an object item for which payment is to be made 



when the object item is not executed within the ex- 
ecution term of the object item. 

32. The system according to any preceding claim, 
5 wherein 

said payee has: 

means (7600) for monitoring an execution term, 
contained in payment condition information, for 
10 the object item for which payment is to be 

made; and 

means (7600) for notifying one of a payer and 
a confirmor who confirms the object item for 
which payment is to be made when the object 
15 item is not executed within the execution term. 

33. An electronic money settlement system comprising: 

means (1) for transferring, to a payee, electron- 
ic ic money, that is, money information which con- 
tains information identifying whether or not pro- 
visional settlement information is contained, 
and is settled according to a notification of con- 
firmation that an object item for which payment 
25 js to be made has been executed; and 

means (3) for making final settlement for the 
money information containing the provisional 
settlement information based on confirmation 
that the object item for which payment is to be 
30 made has been executed. 

34. The system according to claim 33, wherein 

said money information containing the provi- 
sional settlement information is stored in a portable 
35 storage medium (82). 

35. The system according to claim 34, wherein 

said portable storage medium is issued from 
a terminal unit (80, 80') connected to an issuing fi- 
40 nancial institution of a payer. 

36. The system according to claim 34, wherein 

said portable storage medium can be applied 
to a terminal unit connected to an issuing financial 
45 institution of the payee, and the terminal unit com- 
prises means (3010, 3020) for transmitting a final 
settlement request according to the provisional set- 
tlement information stored in the portable storage 
medium. 

so 

37. The system according to claim 36, wherein 

said terminal unit comprises means (3003, 
301 0) for collecting the portable storage medium af- 
ter the payee has issued the final settlement re- 
ss quest. 

38. The system according to claim 37, wherein 

said terminal unit comprises means (3001, 
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3010) for writing information inhibiting a re-use of 
the portable storage medium upon normal comple- 
tion of a process for the final settlement request. 

39. The system according to any of claims 33 to 38, fur- 
ther comprising: 

means (5400) for storing a final settlement re- 
quest from the payee; 

means (5400) for storing a final settlement ad- 
mission (permission) request from the payer; 
and 

means (5700) for performing the final settle- 
ment based on the stored final settlement re- 
quest and final settlement admission request. 

40. The system according to claim 39 t wherein 

said final settlement request contains request 
for receipt of transfer information containing trans- 
fer destination. 

41 . The system according to any of claims 33 to 40, fur- 
ther comprising: 

a transaction management device (5) for me- 
diating transmission and receipt of transaction in- 
formation. 

42. The system according to claim 41 ; wherein 

said transaction management device com- 
prises transaction information management means 
(55) for storing the transaction information with au- 
thentication information about a transmitter 

43. The system according to claim 41 : wherein 

said transaction management device com- 
prises means (1500) for monitoring a transaction 
cancellation request from the payee. 

44. The system according to claim 43 ; wherein 

said transaction management device com- 
prises means (1500) for issuing a cancellation re- 
quest on behalf of the payee when the transaction 
management device does not receive the cancella- 
tion request from the payee within a predetermined 
period. 

45. The system according to any of claims 41 to 44, 
wherein 

said transaction management device com- 
prises means (1500) for monitoring whether or not 
one of a final settlement admission request and a 
ret urn -of -goods request is issued by a goods re- 
ceiver after the goods receiver has received goods 
when the object item for which payment is to be 
made relates to goods. 

46. The system according to claim 45, wherein 

said transaction management device com- 



prises means (1500) for issuing the final settlement 
admission request on behalf of the goods receiver 
when none of the final settlement admission re- 
quest and the return -of -goods request are issued 
5 within a predetermined period. 

47. The system according to claim 45, wherein 

said transaction management device com- 
prises means (1500) for issuing a transaction can- 
70 cellation request when a return-of-goods procedure 
is followed. 

48. The system according to any of claims 41 to 46, 
wherein 

'5 said transaction management device com- 

prises: 

means (1500) for monitoring at least one of a 
final settlement admission request and a re- 

20 turn-of-goods request; and 

means (1500) for transmitting third-party deliv- 
ery certification information containing a pay- 
ment identifier relating to purchase of goods as 
authentication information and issuing the final 

25 settlement admission request when none of the 

final settlement admission request and the re- 
turn-of-goods request are issued. 

49. The system according to any of claims 41 to 46, 
30 wherein 

said transaction management device com- 
prises means (1500) for transmitting third-party re- 
turn-of-goods certification information containing a 
payment identifier relating to purchase of goods as 
35 authentication information and issuing a transaction 
cancellation request. 

50. The system according to claim 49 : further compris- 
ing: 

40 

means (5700) for monitoring a return-of-goods 
claim notification from one of a seller and a 
transaction management device after the 
goods have been returned; and 
45 means (5700) for reserving a transaction can- 

cellation process when the return-of-goods 
claim notification is received within a predeter- 
mined period. 

50 51. The system according to claim 50, further compris- 
ing: 

means (5700) for immediately performing the 
transaction cancellation process even within the 
predetermined period when a returned goods re- 
ss ceipt notification is received from one of the seller 
and the transaction management device. 

52. The system according to any of claims 41 to 51 , 
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wherein 

,said transaction management device com- 
prises: 

means (1 500) for monitoring an execution term, 5 
contained in payment condition information, of 
the object item for which payment is to be 
made; and 

means (1 500) for transmitting the payment con- 
dition information as authentication information 10 
and issuing a transaction cancellation request 
when the object item is not executed within the 
execution term. 

53. An encryption intermediate system having a trans- is 
action management device (5) for mediating trans- 
mission from a first party to a second party, com- 
prising: 

means (1, 2, 3, 4) for encrypting data using a 20 
unique encryption key between the first party 
and the transaction management device when 
the first party transmits the data to the second 
party; and 

means (1 , 2, 3, 4) for requesting the transaction 2S 
management device to transmit encrypted data 
to the second party. 

54. The system according to claim 53 : wherein 

said transaction management device com- 30 
prises means (1500) for decrypting data received 
from the first party using a unique decryption key 
between the first party and the transaction manage- 
ment device. 

35 

55. The system according to claim 54 : wherein 

said transaction management device com- 
prises means (1500) for encrypting decrypted data 
using a unique encryption key between the second 
party, that is : a destination of the data, and the trans- 40 
action management device. 

56. A delivery system having a processing unit (2) of a 
seller of goods, a processing unit (1 ) of at least one 

of a purchaser and a receiver of the goods, and a 45 
delivery management device (6, 6') provided for a 
deliverer of the goods, wherein 

said delivery management device comprises: 

means (60, 60') for storing delivery information so 
based on a delivery request from the seller's 
processing unit; and 

means (4480) for generating third-party deliv- 
ery certification information containing a signa- 
ture of the receiver of the goods and a payment ss 
identifier relating to purchase of the goods 
when the deliverer has delivered the goods to 
the receiver. 



57. The system according to claim 56, further compris- 
ing: 

a transaction management device (5) for medi- 
ating transmission and receipt of at least a part 
of transaction information among the seller, 
purchaser, receiver, and deliverer, wherein 
said transaction management device compris- 
es means (55) for storing at least one of the 
third-party delivery certification information in- 
cluding the payment identifier, first third-party 
return-of-goods certification information, and 
second third-party return-of-goods certification 
information. 

58. A delivery system having a processing unit (2) of a 
seller of goods, a processing unit (1 ) of at least one 
of a purchaser and a receiver of the goods, and a 
goods delivery management device (6, 6') provided 
for a deliverer of the goods, wherein 

said goods delivery management device 
comprises: 

means (60, 60') for storing return-of-goods de- 
livery information based on a returned goods 
delivery request from the receiver; and 
means (4480) for generating first third-party re- 
turn-of-goods certification information contain- 
ing a signature of the receiver and a payment 
identifier relating to purchase of the goods. 

59. The system according to claim 58, further compris- 
ing: 

a transaction management device (5) for medi- 
ating transmission and receipt of at least a part 
of transaction information among the seller, 
purchaser, receiver, and deliverer, wherein 
said transaction management device compris- 
es means (55) for storing at least one of the 
third-party delivery certification information in- 
cluding the payment identifier, first third-party 
return-of-goods certification information, and 
second third-party return-of-goods certification 
information. 

60. The system according to claim 58, further compris- 
ing a returned goods delivery management device 
(7, 6') provided for a deliverer for delivering returned 
goods, wherein 

said returned goods delivery management 
device comprises means (4480) for generating sec- 
ond third-party return-of-goods certification infor- 
mation containing a receipt signature of the seller 
and the payment identifier in the retu med goods de- 
livery information. 

61. The system according to claim 60, further compris- 
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ing: 

a transaction management device (5) for medi- 
ating transmission and receipt of at least a part 
of transaction information among the seller, 
purchaser, receiver, and deliverer, wherein 
said transaction management device compris- 
es means (55) for storing at least one of the 
third-party delivery certification information in- 
cluding the payment identifier, first third-party 
ret urn -of -goods certification information, and 
second third-party ret urn -of -goods certification 
information. 

62. A digital contents sales system having at least a 
seller's processing unit (2), a purchaser's process- 
ing unit (1), and a mediating transaction manage- 
ment device (5), wherein 

said transaction management device com- 
prises: 

management means (55) for managing a de- 
cryption key of digital contents to be sold 
through the seller's processing unit; and 
means (1020, 1500) for transmitting the de- 
cryption key to the purchaser's processing unit 
at a demand from the purchaser's processing 
unit. 

63. The system according to claim 62 ; wherein 

said transaction management device com- 
prises means (1500) for generating third-party wit- 
ness information by adding a signature of the pur- 
chaser and authentication of the transaction man- 
agement device when the decryption key is trans- 
mitted to the purchaser's processing unit. 

64. The system according to claim 62 s wherein 

said transaction management device com- 
prises: 

means (1020, 1500) for receiving a notification 
from the purchaser's processing unit that the 
digital contents cannot be decrypted using the 
decryption key; and 

means (1500) for comparing the digital con- 
tents received from the seller's processing unit 
with the digital contents returned from the pur- 
chaser's processing unit. 

65. The system according to claim 64, wherein 

said transaction management device com- 
prises means (1500) for decrypting the digital con- 
tents using the decryption key when a comparison 
result indicates a coincidence. 

66. The system according to claim 65, wherein 

said transaction management device com- 



prises: 

means (1020, 1500) for re-demanding the sell- 
er's processing unit for digital contents encrypt- 
s ed using a unique encryption key between the 

transaction management device and the sell- 
er's processing unit; and 
means (1500) for comparing decrypted digital 
contents with re-demanded digital contents. 

1 ° 

67. The system according to claim 66, wherein 

said transaction management device com- 
prises means (1020, 1500) for assuming that the 
decryption key transmitted to the purchaser's 
*5 processing unit is defective when compared digital 
contents match each other, and re-transmitting a 
decryption key. 

68. The system according to claim 66, wherein 
20 said transaction management device com- 
prises means (1020, 1500) for assuming that the 
digital contents transmitted to the purchaser's 
processing unit is defective when compared digital 
contents do not match each other, and notifying the 

25 seller's processing unit of a defect. 

69. The system according to any of claims 64 to 68, 
wherein 

said transaction management device com- 
30 prises means (1020, 1500) for re -transmitting the 
digital contents received from the seller's process- 
ing unit to the purchaser's processing unit when 
compared digital contents do not match each other. 

35 70. A transaction management device (5) which medi- 
ates transmission of data from a first party to a sec- 
ond party, comprising: 

means (1020) for receiving data through a 
40 unique encryption protocol between the first 

party and the transaction management device; 
and 

means (1020, 1500) for transmitting the re- 
ceived data through a unique encryption prolo- 
gs col between the second party and the transac- 
tion management device. 

71. A transaction management device (5) which medi- 
ates a provisional settlement process performed at 
50 a notification of confirmation that an object item for 
which payment is to be made has been executed, 
comprising: 

means (1500) for monitoring at least one of a 
55 final settlement admission request and a re- 

turn-of -goods request to be issued after a re- 
ceiver of goods has received the goods; and 
means (1 500) for transmitting third-party deliv- 
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ery certification information as authentication 
information and issuing the final settlement ad- 
mission request on behalf of the receiver when 
none of the final settlement admission request 
and the return-of -goods request are issued 
within a predetermined period. 

72. A transaction management device (5) which medi- 
ates a provisional settlement process performed at 
a notification of confirmation that an object item for 
which payment is to be made has been executed, 
comprising: 

means (1500) for monitoring whether or not a 
seller issues a cancellation request through re- 
turn of goods corresponding to said object item; 
and 

means (1500) for transmitting third-party re- 
turn-of -goods certification information as au- 
thentication information and issuingthe cancel- 
lation request on behalf of the seller when the 
cancellation request is not issued within a pre- 
determined period. 

73. A transaction management device (5) for mediating 
sales of digital contents, comprising; 

means (55) for managing a decryption key for 
digital contents encrypted by a seller and trans- 
mitted to a purchaser; 

means (1020, 1500) for transmitting the de- 
cryption key to the purchaser; and 
means (1500) for issuing third-party witness 
certification information. 

74. A transaction management device (5) for mediating 
sales of digital contents, comprising: 

means (1500) for determining whether or not 
digital contents received by a purchaser are de- 
fective; 

means (1020, 1500) for notifying the purchaser 
when it is determined that the digital contents 
are defective; and 

means (1020, 1500) for re-transmitting a de- 
cryption key to the purchaser when it is deter- 
mined that the decryption key is defective. 

75. A transaction management device (5) which medi- 
ates among a delivery management device (6, 6') 
provided for a deliverer of goods, a seller's process- 
ing unit (2), and a purchaser's and receiver's 
processing unit (1), comprising: 

means (1500) for receiving an entry of third- 
party delivery certification information of the de- 
livery management device; 
means (1500) for receiving an entry of first 



third-party return-of-goods certification infor- 
mation certifying that a retum-of-goods request 
has been issued; and 

means (1500) for receiving an entry of second 
5 third-party retum-of-goods certification infor- 

mation certifying that a seller has received re- 
turned goods. 

76. A terminal unit (80, 80') connected to a financial in- 
fo stitution, comprising: 

means (3004) for storing a portable storage 
medium (82) for storing money information con- 
taining provisional settlement information 
is which is settled at a notification of confirmation 

that an object item for which payment is to be 
made has been executed; and 
means (3010) for issuing the portable storage 
medium. 

20 

77. A terminal unit (81 , 80') connected to a financial in- 
stitution, comprising: 

means (3001 ) for reading information stored on 
25 a portable storage medium (82) for storing 

money information containing provisional set- 
tlement information which is settled at a notifi- 
cation of confirmation that an object item for 
which payment is to be made has been execut- 
30 ed; and 

means (301 0, 3020) for transmitting a final set- 
tlement request to a financial institution accord- 
ing to read information. 

35 78. A terminal unit (80, 80') connected to a financial in- 
stitution, comprising: 

means (3001 ) for reading information stored on 
an inserted portable storage medium (82); and 
40 means (3003, 301 0) for automatically collecting 

the portable storage medium after completion 
of a process when the portable storage medium 
stores collection information. 

45 79. A delivery management device (6, 6') provided for 
a deliverer of goods, comprising: 

means (60, 60') for storing goods delivery infor- 
mation based on a goods delivery request from 

50 a seller; and 

means (4480) for generating third-party deliv- 
ery certification information containing a pay- 
ment identifier relating to purchase of the goods 
and a signature of one of a receiver and a sub- 

55 stitute when the deliverer delivered the goods 

to the receiver. 

80. The device according to claim 79, further compris- 
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ing: 

means (4102, 4480) for entering the third-par- 
ty delivery certification information in a transaction 
management device (5). 

81. The device according to claim 79, further compris- 
ing: 

means (4102, 4480) for notifying the seller of 
the third-party delivery certification information after 
delivering goods. 

82. A delivery management device (7, 6') provided for 
a deliverer of goods, comprising: 

means (70, 60') for storing returned goods de- 
livery information based on a returned goods 
delivery request from a receiver of the goods; 
and 

means (4480) for generating first third-party re- 
turn-of -goods certification information contain- 
ing a payment identifier relating to purchase of 
the goods and a signature of one of the receiv- 
er, who issued a return-of -goods request, and 
a substitute. 

83. The device according to claim 82, further compris- 
ing: 

means (4102, 4480) for entering the first 
third-party return-of-goods certification information 
in a transaction management device (5). 

84. The device according to claim 82, further compris- 
ing: 

means (4480) for generating second third- 
party return-of-goods certification information con- 
taining a receipt signature of the seller and the pay- 
ment identifier relating to the purchase of the goods 
when returned goods are delivered to the seller. 

85. The device according to claim 84, further compris- 
ing: 

means (4102, 4480) for entering the second 
third-party return-of-goods certification information 
in a transaction management device (5). 

86. The device according to any of claims 82 to 85, fur- 
ther comprising: 

means (4102, 4480) for issuing, to the receiv- 
er, returned goods delivery acceptance receipt cer- 
tification containing the payment identifier relating 
to the purchase of the goods. 

87. A financial processing device (3,3') provided in a fi- 
nancial institution, comprising: 

means (5700) for accepting a request for an is- 
sue of money information, which is settled upon 
receipt of a confirmation notification that an ob- 



ject item for which payment is to be made has 
been executed, containing provisional settle- 
ment information; 

means (5200, 5300, 5400) for freezing an 
5 amount of the money information within a bal- 

ance of an account of a payer, and managing 
the amount as a non-transferable amount until 
the final settlement is made; and 
means (5700) for issuing the money informa- 
10 tion containing the provisional settlement infor- 

mation. 

88. The device according to claim 87, further compris- 
ing: 

15 means (5700) for writing, in the money infor- 

mation, object information indicating the object item 
for which payment is to be made. 

89. The device according to claim 88, further compris- 
20 ing: 

means (5700) for accepting the money informa- 
tion transferred to a payee and details of an ex- 
ecuted object item for which payment is to be 
25 made; and 

means (5700) for checking validity between the 
object information included in the money infor- 
mation and the details of the executed object 
item. 

30 

90. The device according to claim 87, further compris- 
ing: 

means (5700) for writing, in the money informa- 
35 tion, object information indicating the object 

item for which payment is to be made; and 
means for providing a blind signature for the ob- 
ject information. 

40 91 . A financial processing device (3, 3') provided in a fi- 
nancial institution, comprising: 

means (5700) for accepting a request for re- 
ceipt of transfer of provisional settlement mon- 
45 ey from a payee; 

means (5700) for confirming whether or not a 
final settlement admission request has been is- 
sued; 

means (5700) for performing one of money 
so transfer and transfer of electronic money to the 

payee based on contents of the request for re- 
ceipt of transfer when final settlement admis- 
sion is issued; and 

means (5700) for storing a request for receipt 
55 of transfer information in a database when no 

final settlement admission is issued. 

92. A financial processing device (3,3') provided in a fi- 
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nancial institution, comprising: 

means (5700) for accepting a final settlement 
admission request; and 
means (5700) for checking validity of the ac- 
cepted final settlement admission request. 

93. The device according to claim 92, further compris- 
ing: 

means (5700) for confirming acceptance of a 
final settlement request from a payee when 
contents of the final settlement admission re- 
quest are correct; 

means (5700) for making a payment based on 
contents of a request for receipt of transfer 
when the request is issued in the final settle- 
ment request; and 

means (5700) for issuing a demand notification 
for a final settlement request process. 

94. A financial processing device (3 : 3') provided in a fi- 
nancial institution, comprising: 

means (5700) for accepting a provisional set- 
tlement cancellation request; and 
means (5700) for checking validity of the ac- 
cepted provisional settlement cancellation re- 
quest. 

95. The device according to claim 94, wherein 

said means for checking the validity accepts 
and checks one of first third-party return-of -goods 
certification information certifying that a return-of- 
goods request has been issued and second third- 
party return-of -goods certification information certi- 
fying a receipt of returned goods by the payee, and 
setting the number of days for adjustment when the 
checked third-party ret urn -of -goods certification in- 
formation is correct. 

96. A financial processing device (3^') provided in a fi- 
nancial institution, comprising: 

means (5700) for accepting a provisional set- 
tlement cancellation request; 
means (5700) for accepting a return-of -goods 
claim; and 

means (5700) for reserving a provisional settle- 
ment cancellation process when a return-of- 
goods claim corresponding to a provisional set- 
tlement cancellation request is issued. 

97. A payment processing device (1) provided for a 
payer, comprising: 

means (6800) for issuing a request for money 
information, which is settled upon receipt of a 



confirmation notification that an object item for 
which payment is to be made has been execut- 
ed, containing provisional settlement informa- 
tion; and 

5 means (6300) for storing the money information 

including the provisional settlement informa- 
tion. 

98. The device according to claim 97, comprising: 

10 means (6800) for issuing an entry request for 

object information indicating the object item for 
which payment is to be made in the money informa- 
tion containing the provisional settlement informa- 
tion. 

75 

99. A payment processing device (1) provided for a 
payer, comprising: 

means (6800) for requesting a payee to exe- 
20 cute an object item for which payment is to be 

made; and 

means (6020, 6800) for transferring, to the pay- 
ee, money information, which is settled upon 
receipt of a confirmation notification that the ob- 
25 ject item has been executed, containing provi- 

sional settlement information. 

100. The device according to claim 99, comprising: 

means (6800) for issuing a final settlement 
30 admission request based on confirmation that the 
object item has been executed when an execution 
result is normal. 

101. The device according to 99, further comprising: 

35 

means for issuing a ret urn -of -goods request 
when the contents of goods, which are the ob- 
ject item for which payment is to be made, are 
not normal based on confirmation of the con- 
40 tents of the goods; 

means (6020, 6800) for accepting third-party 
return -of-goods certification information certify- 
ing that the return -of-goods request has been 
received; and 

45 means (6800) for issuing a provisional settle- 

ment cancellation request. 

102. A sales management device (2) provided for a sell- 
er of goods, comprising: 

so 

means (7020, 7600) for accepting an order of 
goods from a purchaser of the goods; 
means (7020, 7600) for accepting money infor- 
mation containing provisional settlement infor- 
55 mation from the purchaser; and 

means (7600) for issuing a final settlement re- 
quest after transmitting the goods to a receiver 
of the goods. 
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103. The device according to claim 102, further compris- 
ing: 

means (7600) for monitoring at least one of a 
final settlement admission request and a re- 
turn-of-goods request after the receiver re- 
ceives the goods; and 

means (7600) for transmitting third-party deliv- 
ery certification information as authentication 
information certifying that the receiver has re- 
ceived the goods, and issuing the final settle- 
ment admission request on behalf of the receiv- 
er when neither of the final settlement admis- 
sion request and the ret um-of- goods request 
are issued within a predetermined period. 

104. The device according to claim 102, further compris- 
ing: 

means (7600) for accepting a notification of a 
cancellation request through return of the 
goods; 

means (7600) for issuing a provisional settle- 
ment cancellation request in response to the 
notification of the cancellation request; and 
means (7600) for requesting a return -of -goods 
claim when the return of the goods is not normal 
based on confirmation of the contents of re- 
turned goods. 

105. A receipt processing device (1) provided for a re- 
ceiver of goods, comprising: 

means (6030) for receiving a result of receipt 
confirmation of goods sent from a seller; and 
means (6800) for issuing a final settlement ad- 
mission request when the goods are normal 
based on the result of the receipt confirmation 
of the goods. 

106. The device according to claim 105, further compris- 
ing: 

means (6800) for issuing a retum-of-goods re- 
quest to return the goods when the goods are 
not normal based on the result of the receipt 
confirmation of the goods; 
means (6020, 6800) for receiving third-party re- 
tum-of-goods certification information certify- 
ing that the return -of-goods request has been 
received; and 

means (6800) for issuing a provisional settle- 
ment cancellation request. 



means (6800) for monitoring an execution term 
for the object item for which payment is to be 
made contained in payment condition informa- 
tion; and 

5 means (6020, 6800) for issuing a transaction 

cancellation request by transmitting the pay- 
ment condition information as authentication in- 
formation when the object item is not executed 
within the execution term. 

10 

108. A sales management device (2) provided for a pay- 
ee, comprising: 

means (7020, 7600) for receiving an object item 
*5 for which payment is to be made from a payer; 

means (7600) for receiving money information, 
which is settled upon receipt of a confirmation 
notification that the object item has been exe- 
cuted, containing provisional settlement infor- 
20 mat ion; 

means for monitoring an execution term for the 
object item for which payment is to be made; 
and 

means (7020, 7600) for notifying one of the 
25 payer and a confirmor who confirms the object 

item when the object item has not been execut- 
ed within the execution term. 

109. A portable storage medium (82) storing money in- 
30 formation, which is transferred to a payee and set- 
tled upon receipt of a confirmation notification that 
an object item for which payment is to be made has 
been executed, containing provisional settlement 
information. 

35 

110. The medium according to claim 109, wherein 

said money information containing the provi- 
sional settlement information includes object infor- 
mation indicating the object item for which payment 
to is to be made. 

111. A computer-readable storage medium (8102, 8105, 
8109, 8110) storing a program used to direct a com- 
puter, which is a transaction management device 

45 (5) for mediating transmission of data from a first 
party to a second party, to perform the functions of: 

receiving data using a unique encryption proto- 
col between the first party and the transaction 
50 management device; and 

transmitting received data using a unique en- 
cryption protocol between the transaction man- 
agement device and the second party. 
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107. A payment processing device (1) provided for one 
of a payer and a confirmor who confirms an object 
item for which payment is to be made, comprising: 



5S 11 2. A computer-readable storage medium (8102, 8105, 
81 09, 81 1 0) storing a program used to direct a com- 
puter, which is a transaction management device 
(5) for mediating a provisional settlement process, 
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to perform the functions of: 

monitoring at least one of a final settlement ad- 
mission request and a return-of -goods request 
to be issued after a receiver of goods has re- 5 
ceived the goods; and 

transmitting third-party delivery certification in- 
formation as authentication information and is- 
suing the final settlement admission request on 
behalf of the receiver when neither of the final 10 
settlement admission request and the return- 
of-goods request are issued within a predeter- 
mined period. 

11 3. A computer-readable storage medium (8102, 8105, '5 
81 09, 81 1 0) storing a program used to direct a com- 
puter, which is a transaction management device 

(5) for mediating a provisional settlement process, 
to perform the functions of: 

20 

monitoring whether or not a seller issues a can- 
cellation request through return of goods; and 
transmitting third-party ret urn -of -goods certifi- 
cation information as authentication informa- 
tion and issuing the cancellation request on be- 
half of the seller when the cancellation request 
is not issued within a predetermined period. 

114. A computer-readable storage medium (8102, 8105, 

81 09, 81 1 0) storing a program used to direct a com- 30 
puter, which is a transaction management device 
(5) for mediating sales of digital contents, to perform 
the functions of: 

managing a decryption key for digital contents 35 
encrypted by a seller and transmitted to a pur- 
chaser; 

transmitting the decryption key to the purchas- 
er; and 

issuing third-party witness certification informa- 40 
tion. 

115. A computer-readable storage medium (8102, 8105, 
81 09, 81 1 0) storing a program used to direct a com- 
puter, which is a transaction management device 
(5) for mediating sales of digital contents, to perform 
the functions of: 

determining whether or not digital contents re- 
ceived by a purchaser are defective; so 
notifying the purchaser when it is determined 
that the digital contents are defective; and 
re-transmitting a decryption key to the purchas- 
er when it is determined that the decryption key 
is defective. ss 

11 6. A computer-readable storage medium (8102, 8105, 
81 09, 81 1 0) storing a program used to direct a com- 



puter, which is a transaction management device 
(5) for mediating among a delivery management de- 
vice (6, 7, 6') provided for a deliverer of goods, a 
seller's processing unit (2), and at least one of a pur- 
chaser's and receiver's processing unit (1), to per- 
form the functions of: 

receiving an entry of third-party delivery certifi- 
cation information of the delivery management 
device; 

receiving an entry of first third-party return-of- 
goods certification information certifying that a 
return-of-goods request has been issued; and 
receiving an entry of second third-party return- 
of-goods certification information certifying that 
a seller has received returned goods. 

1 1 7. A storage medium (81 02, 81 05, 8 1 09, 81 1 0) storing 
a program used to direct a central processing unit 
and an input/output device of a terminal unit (80, 
80') connected to a financial institution to perform 
the function of: 

issuing a portable storage medium for storing 
money information, which is settled at a notification 
of confirmation that an object item for which pay- 
ment is to be made has been executed, containing 
provisional settlement information. 

1 1 8. A storage medium (81 02, 81 05, 81 09, 8110) storing 
a program used to direct a central processing unit 
and an input/output device of a terminal unit (80, 
80') connected to a financial institution to perform 
the function of: 

transmitting to the financial institution a final 
settlement request based on a portable storage me- 
dium storing money information, which is settled at 
a notification of confirmation that an object item for 
which payment is to be made has been executed, 
containing provisional settlement information. 

1 1 9. A storage medium (81 02, 8105, 81 09, 81 1 0) storing 
a program used to direct a central processing unit 
and an input/output device of a terminal unit (80, 
80') connected to a financial institution to perform 
the function of: 

automatically collecting an inserted portable 
storage medium after completion of a process when 
the portable storage medium stores collection infor- 
mation. 

1 20. A computer-readable storage medium (81 02, 81 05, 
8109, 8110) storing a program used to direct a com- 
puter, which is a delivery management device (6, 
6') provided for a deliverer of goods, to perform the 
functions of: 

storing goods delivery information based on a 
goods delivery request from a seller; and 
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generating third-parly delivery certification in- 
formation containing a payment identifier relat- 
ing to purchase of the goods and a receipt sig- 
nature of one of a receiver and a substitute 
when the goods are delivered to the receiver. s 

121. A computer-readable storage medium (8102, 8105, 
81 09, 81 1 0) storing a program used to direct a com- 
puter, which is a delivery management device (7, 

6') provided for a deliverer of goods, to perform the 10 
functions of: 

storing return-of-goods delivery information 
based on a returned goods delivery request 
from a receiver of the goods; and ?5 
generating third-party return-of-goods certifica- 
tion information containing a payment identifier 
relating to purchase of the goods and a signa- 
ture of one of the receiver, who issued a return- 
of-goods request, and a substitute. 20 

1 22. A computer-readable storage medium (81 02, 81 05, 
81 09, 81 1 0) storing a program used to direct a com- 
puter, which is a financial processing device (3,3') 
provided in a financial institution, to perform the 25 
functions of: 

accepting a request for an issue of money in- 
formation, which is settled upon receipt of a 
confirmation notification that an object item for 30 
which payment is to be made has been execut- 
ed, containing provisional settlement informa- 
tion; 

transferring money information from a balance 
of an account of a payer to a provisional settle- 35 
ment balance; 

issuing the money information containing the 
provisional settlement information; and 
issuing authentication of the financial institu- 
tion. 40 



admitted; and 

storing a request for receipt of transfer informa- 
tion in a database when the final settlement is 
not admitted. 

1 24. A computer-readable storage medium (81 02, 81 05, 
8109, 8110) storing a program used to direct a com- 
puter, which is a financial processing device (3,3') 
provided in a financial institution, to perform the 
functions of: 

accepting a final settlement admission request 
for money information, which is settled upon re- 
ceipt of a confirmation notification that an object 
item for which payment is to be made has been 
executed, containing provisional settlement in- 
formation; and 

checking validity of the accepted final settle- 
ment admission request. 

125. A computer-readable storage medium (8102, 8105, 
8109, 8110) storing a program used to direct a com- 
puter, which is a financial processing device (3,3') 
provided in a financial institution, to perform the 
functions of: 

accepting a provisional settlement cancellation 
request for money information, which is settled 
upon receipt of a confirmation notification that 
an object item for which payment is to be made 
has been executed, containing provisional set- 
tlement information; and 
checking validity of the accepted provisional 
settlement cancellation request. 

126. A computer-readable storage medium (8102, 8105, 
8109, 8110) storing a program used to direct a com- 
puter, which is a financial processing device (3,3*) 
provided in a financial institution, to perform the 
functions of: 



123. A computer-readable storage medium (8102, 8105, 
8109, 8110) storing a program used to direct a com- 
puter, which is a financial processing device (3,3') 
provided in a financial institution, to perform the 
functions of: 

accepting a request for receipt of transfer of 
money information, which is settled upon re- 
ceipt of a confirmation notification that an object 
item for which payment is to be made has been 
executed, containing provisional settlement in- 
formation; 

confirming whether or not a final settlement ad- 
mission request has been issued; 
transferring one of money and electronic mon- 
ey to a payee based on contents of the request 
for receipt of transfer when a final settlement is 



accepting a provisional settlement cancellation 
request for money information, which is settled 
upon receipt of a confirmation notification that 
an object item for which payment is to be made 
has been executed, containing provisional set- 
tlement information ; 
accepting a ret urn -of -goods claim; and 
reserving a provisional settlement cancellation 
process when a return-of-goods claim corre- 
sponding to a provisional settlement cancella- 
tion request is issued. 

1 27. A computer-readable storage medium (81 02, 81 05, 
81 09, 81 1 0) storing a program used to direct a cen- 
tral processing unit and an input/output device, 
which form a payment processing device (1 ) provid- 
ed for a payer, to perform the function of: 
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requesting an issue of money information, 
which is settled upon receipt of a confirmation noti- 
fication that an object item for which payment is to 
be made has been executed, containing provisional 
settlement information. 5 

128. A storage medium (8102, 8105, 8109, 8110) storing 
a program used to direct a central processing unit 
and an input/output device, which form a payment 
processing device (1) provided for a payer, to per- 
form the functions of: 

requesting a payee for an object item for which 
payment is to be made; and 
transferring money information, which is settled 
upon receipt of a confirmation notification that 
the object item for which payment is to be made 
has been executed, containing provisional set- 
tlement information. 

20 

129. A computer-readable storage medium (8102, 8105, 
81 09, 81 1 0) storing a program used to direct a com- 
puter, which is a sales management device (2) pro- 
vided for a seller of goods, to perform the functions 

of: 25 



1 32. A computer-readable storage medium (81 02, 81 05, 
8109, 8110) storing a program used to direct a com- 
puter, which is a sales management device (2) pro- 
vided for a payee, to perform the functions of: 



accepting an object item for which payment is 
to be made from a payer; 
accepting money information, which is settled 
upon receipt of a confirmation notification that 
'0 an object item for which payment is to be made 

has been executed, containing provisional set- 
tlement information; 

monitoring an execution term, for the object 
item for which payment is to be made, included 
f5 in payment condition information; 

notifying one of the payer and a confirmor who 
confirms the object item for which payment is 
to be made when the object item is not execut- 
ed within the execution term. 



accepting an order of the goods from a pur- 
chaser of the goods; 

accepting money information containing provi- 
sional settlement information from the purchas- 30 
er; and 

requesting for a final settlement after delivering 
the goods to a receiver. 

1 30. A storage medium (8102, 8105, 8109, 81 1 0) storing 35 
a program used to direct a central processing unit 
and an input/output device, which form a receipt 
processing device (1) provided for a receiver of 
goods, to perform the function of: 

issuing a final settlement admission request 40 
when the goods are normal based on a receipt con- 
firmation of the goods delivered from a seller. 

131. A storage medium (8102, 8105, 8109, 8110) storing 

a program used to direct a central processing unit 45 
and an input/output device, which form a payment 
processing device (1 ) provided for one of a payer 
and a confirmor who confirms an object item for 
which payment is to be made, to perform the func- 
tions of: 50 



monitoring an execution term for the object item 
for which payment is to be made included in 
payment condition information; and 
issuing a transaction cancellation request by 55 
transmitting the payment condition information 
as authentication information when the object 
item is not executed within the execution term. 
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